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The Sound of J erry 



Jerry L ewis breaks character: "L is- 
ten...lay-DEEE !" It's not much, 
just a single word delivered in 
that characteristic way, but the 
audience goes nuts Everyone on 
stage freezes for probably a good 
15 seconds while the M arquis 
T heatre roars with approval. T he 
septuagenarian has let the audience know 
that tonight it's not going to be the saintly, 
Brylcreem- haired, (ex-) chain-smoking, 
dear-dear-friend-of-Liza, nominated-for- 
a-N obel-Peace-Prize, hyper-earnest shill 
with the 21-hour Labor Day patter. 
Tonight, it's going to be the zany, wacky 
goofball with the (once-) rubber skeleton, 
the Geisha Boy, the N utty Professor, the 
Jim-Carrey-Eat-Your-H eart-Out daffy 
laughmeister. T onight, we know, there will 
beshtick. 

Jerry Lewis is playing A pplegate (aka 
The Devil) in the Broadway revival of 
D amn Yankees!, and the audience is filled 
with people with the good sense to turn up 
their noses at Beauty and T he Beast, Sunset 
Boulevard, Cats!, and half a dozen other 
spectacles for which stage effects and the 
sheer shock of live orchestral music played 
competently stand in for.. .well, what? The 
Damn Yankees! sets are spare, filled with 
pastels, forced- perspective, and dressed 
with what look like authentic chrome-and- 
bakelite radios, toasters, and card tables. 
T here's some of the stage magic demanded 
of a Broadway show nowadays, with sets 
rolling on and off silently, descending from 
the catwalks, popping up through trap- 
doors, a shim or two, and so forth, but you 
get the feeling it's the bare minimum 
required by the unions The cast isfabulous 
both in form (when C harlotte d'A mboise, 
playing Lola, first appears, I do the whole 
Tex Avery thing: my eyes pop three feet, 
smoke shoots from my ears, and I involun- 
tarily scream "H ooga-hooga!") and func- 
tion, but I 'm sure the various A ndrew 
L loyd W ebber spectaculars offer at- least- 



similar levels of competence. 

Damn Yankees! succeeds in plastering 
a goofy grin on your face for two- and- a- 
half hours not through any one thing 
(although the presence of the King of 
Comedy is obviously what draws a full 
theater every night), but through a balance 
of elements that are a lesson to anyone in 
digital entertainment. The play itself is 
fluff, even by the standards of 50s musi- 
cals. The book is fine but not particularly 
familiar (the only song you're likely to rec- 
ognize is "[You gotta' have] H eart."). 
I ndeed, it's the very modesty of the play, 
coupled with professional delivery, that 
makes it so enjoyable. 

You don't need state-of-the-art spec- 
tacle to entertain. Indeed, state-of-the-art 
spectacle can easily overwhelm a modest 
entertainment. Although I know I'm in the 
minority, I've always felt that Doom was 
inferior to Castle W olfenstein 3-D, its 
technically limited predecessor. That's one 
reason I was doubly delighted when the 
programming wizards at id made the 
source code for W olfenstein available for 
public perusal (you can download it from 
our ftp site or CompuServe forum; the file- 
name is W L F3D SC .Zl P). 

W hat you need is the enthusiasm and 
courage to make the game you want to 
make. A little talent helps, but it's not as 
important as heart. W hen others say you 
can't win, that's when the grin should start. 
You gotta have heart... Oops. There I go 
with that damnably hummable tune from 
the show again. ■ 

Larry O'Brien 
Editor 

Here is the final verdict on accessing 
Game Developer code. Go to our ftp 
site at ftp://ftp.mfi.com/gamedev/ 
pub/src. If you're using Compuserve, 
GO SDFORUM . That's it. W e 
promise. 
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CROSSFIRE 



A 3D Benchmark 
for -the Industry 



Alex Dunne 

Creating a method to 
game plao. madness 
mag help consumers 
decide nihat games 
mill uiorh best on their 
systems. Development 
of this industry-wide 
standard won't be 
easy-will you be 
involved? 



Recently, I began receiving a 
steady stream of e-mail from 
K en N icholson of AT I 
Technologies. Ken's an 
active member of the 
G amePC C onsortium, a 
group of close to 100 mem- 
ber companies, each of 
which has a hand in the game develop- 
ment arena, including title developers, 
tool vendors, system manufacturers, 
chip, and board manufacturers. The 
stated goal of the consortium is a sim- 
ple and noble one: to raise the level of 
game play on I BM PC s and compati- 
bles. 

T he e-mail that Ken sent consist- 
ed of discussion threads about two 
related issues that are long overdue for 
addressing: a three-dimensional 
graphics benchmark and a hardware 
specification for PC game play. 

The intent of both issues is to 
provide consumers with a way to look 
at a game on the store shelf and tell 
whether the title will run adequately 
on their system. It's far from an easy 
task to get an entire industry (or even a 
portion!) to agree upon sticky issues 
like these, but if a middle ground is 
reached, it will be a huge leap forward 
for consumers and developers alike. 

This month, I'm going to focus 
on the consortium's proposal for an 
industry-wide three-dimensional 
benchmark that would serve as one of 
the components within their second 
aim, the G amePC hardware specifica- 
tion. L ike the M ultimedia PC W ork- 
ing Group's M PC specification for 
multimedia hardware, the GamePC 
Consortium wants to create a symbol 



or trademark that would indicate the 
level of hardware required for different 
games. 

A Ithough the ideas are still being 
bantered around, I imagine the rating 
system would be two or three tiered, 
each tier representing a computer with 
progressively more power and capabili- 
ty. Using this rating system on game 
boxes would instantly indicate to con- 
sumers the type of system required to 
enjoy the game. A rating of this sort 
necessitates the hardware manufactur- 
ers getting involved because it's their 
products that will be rated. M any 
companies have jumped on board 
already. 

The hurdles to developing a 
three-dimensional benchmark, as you 
might surmise, are fairly large. Bench- 
marks are notoriously hard to devise 
and maintain, even when you don't 
have to reach a consensus across the 
industry. The idea of using 
M icrosoft's Funstones benchmark 
(which isn't available yet) or asking an 
independent organization such asZiff 
(the folks at PC Week L abs) to develop 
a benchmark been discussed. 
Although either of these scenarios 
may come true, right now the three- 
dimensional benchmark development 
is in the hands of the industry-of 
which you are a part. 

The discussions by consortium 
members about the benchmark have 
been very insightful. Although this 
article represents an excerpt of the dis- 
cussion, it gives you an idea of the 
problems that have to be solved before 
devising a standard three-dimensional 
benchmark. 
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Define What's 
Being Tested 

First, Rob G lidden of SoftPress cut 
right to the question that was rolling 

1'iimiiniinj 

If you are interested in finding out 
more about the GamePC Consor- 
tium or want membership infor- 
mation, the group can be reached 
at: 

• http://www.mmwire.com/gamepc/ 
gpchome.html 

• CompuServe: GO GAMEPC 

• or contact Ken Nicholson of ATI 
Technologies at 75300.2772® com- 
puserve.com. 

Here's an sampling of GamePC Consor- 
tium member companies: 

GAME DEVELOPERS: 

Acclaim 

Accolade 

Broderbund 

Interplay 

Lucas Arts 

Maxis 

Microprose 

Origin 

Spectrum Holobyte 

TOOL VENDORS: 

Argonaut 

Autodesk 

Caligari 

Intel 

SYSTEM VENDORS: 

Acer 

Apple 

IBM 

CHIP AND BOARD MANUFACTURERS: 
ATI 

Cirrus Logic 

Creative Labs 

Diamond Multimedia 

Matrox 

MediaVision 

Trident 

VLSI 

Weitek 

Yamaha 



around in my head: "W hat are you 
testing: the 3D API, the chip, the 
board, the host processor, the device 
driver, or a 3D application? All these 
are in the pipeline for getting a 3D 
image to the screen. You need a way to 
isolate out the relative performance 
contribution of one aspect. To do this, 
you need a baseline and a flexible 
enough implementation so that no one 
is left out." 

G lidden proposed finding one or 
more games that run on a number of 
different chip sets and using the games' 
frame rates on each configuration as an 
indicator of performance. H e then 
explained the drawback: every chip 
maker would have to make sure that 
those particular games ran well on their 
chip sets. There's also the problem of 
finding the proper game to exercise all 
facets of the hardware within a short 
enough time without having to jump to 
different scenes, levels, or whatever to 
get the right mix of animations. 

G lidden also submitted ideas for 
measuring polygons per second, pixels 
per second, and frames per second. 
Each, he explained, has its Achilles 
heel as well: What size polygons, and 
how many vertices? Are pixel fill num- 
bers too abstract for consumers? 
Frames per second containing what 
kind of objects? These questions were 
insightful, and Glidden's final com- 
ment was also good: there's a qualita- 
tive element that cannot be objectively 
measured by a benchmark. For 
instance, one chip set that blows away 
another on a frame rate benchmark 
displays inaccurate colors. W hich is 
better in that case? 

Another person who echoed the 
concerns of basing a three-dimensional 
benchmark on objective vs. subjective 
yardsticks was Dan W ood of M atrox. 
H e summed it up like this: "A word of 
warning— testing three-dimensional 
accelerators will be very difficult, as 
most hardware.. .will offer different lev- 
els of quality and features besides 
speed. In some cases, boards may be 
able to achieve very high frame-per- 
second rates, while rendering very low 
quality. U nfortunately, image quality is 



a very difficult thing to account for in 
benchmarking." It's a problem that I 
certainly don't see any easy way 
around, short of appointing someone 
or a group to subjectively judge the 
quality of rendered images. And that's 
opening a whole new can of worms. 

Coping with the 
Three-Dimensional API 

To account for the effect of the three- 
dimensional API on hardware tests, 
there were a number of suggestions: 

• Everyone could agree to standardize 
on one A P I for the testing. D an 
W ood as well as L ou L ong of ki 
Advanced Products suggested using 
M icrosoft's 3D DDI or I ntel's 3D R . 
H owever, this may have to wait 
until the day when either of these 
APIs is in widespread use. An inter- 
im solution would have to be found 
until that day comes, if ever. 

• The group could optimize the 
benchmark for each API. However, 
that situation would be quite a chore 
for the consortium (which is young 
and probably not too flush with 
cash). Because the benchmark would 
have to be optimized for every API, 
the consortium would have to main- 
tain multiple benchmarks over a 
period of timeastheAPIsevolved. 

• The group could devise the bench- 
mark to be API independent. In my 
mind, this seems to be the best 
option. 

To illustrate how an API-free 
benchmark could be accomplished, 
N eil T revett of 3D L abs proposed a test 
of the whole system, analogous to 
G lidden's idea. H e would devise a real- 
istic test, one that required moving 
overlapping three-dimensional objects, 
hidden surface removal, and back-face 
culling in front of a textured back- 
ground (he suggested multiple spheres, 
cubes, and so on, bouncing around and 
colliding in a three-dimensional box). 

The benchmark would specify 
what textures to use, the lighting, the 
position of the eye, and other details. 
Then, when the benchmark is tightly 
specified, the source and binaries 
would be distributed to the various 
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hardware companies, and they could 
use whatever API they wished for the 
testing, as long as the resulting anima- 
tion was identical to the specification. 
This would also mimic the optimiza- 
tions that game developers make for 
various hardware. 

Oh Yeah-the 
Other Platforms 

W hile virtually everyone involved in 
the discussion was focused on W in- 
dows 95 as the testing platform, Dave 
Thielen of W indward Studios remind- 
ed everyone that there were other oper- 
ating systems and environments to 
consider. 

"This benchmark needs to run on 
Winl6, W in/NT, and OS/2 as well as 
W indows 95," T hielen said. "I n all the 
hoopla over W indows 95, everyone 
seems to have forgotten that W i n 16 
still owns the desktop market and 
OS/2 has 10%-while W indows 95 has 
0%." Very good point, and one I hope 
people don't overlook. As I mentioned 



last time ("T he W indows 95 G ame 
Plan," August/September 1995), the 
market for W indows 95 is not going to 
kill the D S and W inl6 game market 
overnight, and it bears some considera- 
tion in whatever three-dimensional 
benchmark is adopted. 

Testing Conditions 

nee the G amePC C onsortium agrees 
on a standard benchmark, whether it's 
API independent or dependent, it must 
specify the conditions under which the 
benchmark will be run. The tests must 
occur in an environment every compa- 
ny can duplicate, and none can deviate 
from in the interests of a better perfor- 
mance rating. Lou Long explained that 
the test "...must state the physical para- 
meters like the width and height of the 
window (if not full screen) in pixels, 
the depth (bits per pixel), the color 
mode (palletized or true color), and 
any other parameter that affects the 
total number of bits rendered by the 
hardware." 



So, as you can see, a flock of issues 
must be dealt with before a PC three- 
dimensional benchmark is finalized. 
D espite the technical hurdles, I believe 
the benchmark will be here sooner 
rather than later. If you'd like to throw 
your two cents into the discussion, I 've 
included the contact information for 
theGamePC C onsortium. You may be 
testing your own games with this 
benchmark in the near future, so it's 
worth the time to donate input. Next 
time I'll examine the plans for a 
GamePC hardware level; it is akin to 
M PC hardware ratings of which the 
three-dimensional benchmark is but a 
single part. ■ 



Alex D unne is a contributing editor 
for Game Developer magazine. Contact 
him via e-mail at 75010. 2665@com- 
puserve.com or through G ame D eveloper 
magazine. 
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Sweet 

Animation 

Suite 



Nicole Claro 
Barbara Hanscome 

Sound, animation, 
upgrades, trade 
shows, and 
gossip.These are the 
tools of the trade. 
Here's a sampling of 
some neiu and 
upcoming stuff gou 
might want to 
chech out. 



Even though you shouldn't put 
all your eggs in one basket, 
count your chickens before 
they hatch, or put the old cart 
before the horse, you should 
try to keep all your develop- 
ment tools in one place. W hat 
better way to expedite three- 
dimensional animation than with a full 
suite of tools at your fingertips? 

Crystal graphics is now shipping 
just such a product. The company's new 
Crystal Kaleidoscope (pictured here 
however minutely) is centered around 




CrystalGraphics's Kaleidoscope features 
a quartet of powerful rendering and ani- 
mation tools built around the core of the 
company's TOPAS technology. 



TO PAS Professional 5.1 a three-dimen- 
sional modeling, rendering, and anima- 
tion package for the PC. Also included 
are Fractal Design Painter 3.1 (to create 
natural-looking art from calligraphy to 
oils to airbrushes), Kai'sPowerTools2.0 
SE (gradients, textures, and filters), 
Elastic Reality 1.01 (for morphing and 
special effects), and Leadview 3.0 (for 
managing and compressing images). 
E ach tool has won awards on its own. I n 



addition, the set comes with four CD- 
ROMS with textures, images, and three- 
dimensional models from a variety of 
other manufacturers. Crystal Kaleido- 
scope retails for $1,995. 

■ For more information contact: 
CrystalGraphics Inc. 
3110 Patrick Henry Dr. 
Santa Clara, Calif. 95054 
Tel: (408) 496-6175 
Fax: (408) 496-0970 

Bring Hie Noise 

Now you can perform a post- recording 
cleansing on any game audio you create. 
Tracer Technologies recently began 
shipping its Digital Audio Reconstruc- 
tion Technology (DART) software. 
DART removes all surface noise, pops, 
clicks, and other disturbances from any 
audio source. As long as you're using a 
W indows-compatible sound card, you 
can use DART. 

After recording, the software 
applies TriC leanse, a three-part process 
that includes a smoothing processor, a 
postfiltering processor, and an outlier 
detector. The first component smooths 
and reconstructs the signal, the second 
removes surface noise, hiss, and any 
other distortion, the third searches for 
hard noises, such as pops and clicks, and 
automatically removes them. You can 
even keep the noise you've removed in a 
separate file and reapply different levels 
of the TriC leanse process until you're 
satisfied with the sound quality. DART 
also features Soundtree, which lets you 
review several takes of a sound file and 
choose your favorite one. Its toolbox 
includes an eight-band graphic equalizer; 
cut, copy, and paste editing; sound left 
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and right splitter; low, high, bandpass, 
and notch filtering; visual and audio 
markers; unlimited active windows; a 
gain adjuster; and a mixer application. It 
retails for $399. 

■ For more information contact: 
Tracer Technologies Inc. 
P.O. Box 188 
Dallastown, Pa. 17313 
Tel: (717) 747-0200 
Fax: (717) 741-6709 

Digitize, Digitize, Digitize! 

Looking to make realistic, three-dimen- 
sional models in less time? Check out 
Vertisketch 2.0, a new plug-in from 
Idaho's B levins enterprises. (I spent two 
days in Boise on a recent road trip. I am 
now officially a seasoned traveler.) 

Vertisketch 2.0 is designed for use 
with Lightwave 3D 4.0 and any sup- 
ported three-dimensional digitizer. It 
features many new functions such as 
lofting, which automatically creates 



Vertisketch lets you create lifelike 
three-dimensional models with the sim- 
ple stroke of a digitizing brush. 



polygons, and autosurf, which creates a 
surface at the stroke of a key. Vertisketch 
2.0 comes in two different models, one 
that relies on a footswitch alone and one 
that incorporates a rotating digitizing 
platform. 



■ For more information contact: 
Blevins Enterprises 

121 Sweet Ave. 
Moscow, Id. 83843 
Tel: (208) 885-3805 
Fax: (208) 885-3803 

Iiuo-Legged Wonders 

To accompany its upcoming 3D Studio 
MAX (the newest version of 3D Studio 
for Windows NT), Autodesk has 
announced Biped, a software product for 
creating lifelike, free- form animations of 
two-legged characters. 

A ccording to A utodesk, the techno- 
logically advanced software combines sev- 
eral innovative techniques with advanced 
inverse kinematics and skinning functions 
which let the characters move at any pace. 
Gait, arm swing, and center of gravity 
will automatically correspond to any pace 
you create. You use Biped by creating a 
set of character footprints, which you 
then manipulate easily. C hange the posi- 
tion and time on the ground of one foot- 
print from the next, and your creation can 
walk, run, stagger, dance, jump, flip, or 
any variety of these movements. Biped 
features three elements that allow for this: 
step-driven animation, free-form 
keyframing, and physics-based interpola- 
tion. It also includes a skeletal/skin defor- 
mation module for creation of seamless 
joints and realistic muscles and body mass 
changes as a character moves over time. 
Biped and 3D Studio MAX will ship 
sometime in 1996. 

■ For more information contact: 
Autodesk Inc. 

Ill Mclnnis Pkwy. 
San Rafael, Calif. 94903 
Tel: (415) 507-6112 
Fax: (415) 507-6112 



Christmas Crunch Sneak 
Attack.. .As we move into Christmas 
crunch season id has, with one master 
stroke, subverted the competition's pro- 
grammers by releasing the source code 
for Wolfenstein 3-D. W hat game pro- 
grammer could resist delving into J ohn 
Carmack's code to the detriment of his 
or her current deadline? The source is 
available on the Internet from ftp.idsoft- 
ware.com or on CompuServe in the 
GAM DEV library. There's an intro by J ohn 
Carmack pointing out what's cool and 
what needs updating. 

Shareware Authors out for 
blood. ..Game authors are on the warpath 
against unscrupulous publishers who take 
shareware to retail and CD-ROMs without 
permission. Apogee, id, MVP, Red- 
wood Games, and TriSoftare all sicc- 
ing lawyers on these pirates. With the 
entry of Interplay's Descent into the 
shareware market, we may see some 
expert copyright muscle behind this effort. 
Question: What giant distributor/publisher 
told a developer whose game it had pirat- 
ed, "We're so big we can use our petty 
cash fund to keep you tied up fighting us 
until you go bankrupt"? 

Musical Chairs. ..Matt Gruson has 
joined Disney Interactive because he 
"saw a lot of interesting opportunities 
and the chance to work under an experi- 
enced management team." Gruson 
(whose first big game was Earthrise 
back in the 80s) founded the Graphic 
Adventure Group at Microprose, 
developed the MADS game engine 
which was used in Rex Nebular (still on 
the top 100 list of games), and then went 
to Sanctuary Woods. He says the 
Graphic Adventure Group was "the 
most energetic and wonderful group," 
and his goal is to get together with a 
group like that again. W hen asked if he'll 
try to reassemble the crew (some of 
whom followed him to Sanctuary), he 
replied, "No comment." 

Sega Exodus. ..Wallace Poulterhas 

left Sega to become an Executive Produc- 
er of GameTek's new sports division. In 
a switch, instead of Poulter having to 
move to Florida, GameTek will move to the 
San Francisco Bay Area. Relocating all 
those Sega folks they picked up must 
have looked more expensive than moving 
the whole company. Others jumping from 
Sega to GameTek include Tom Reuter- 
dahl (now VP of development) and Andy 
J ohnson, who will work under Poulter. 
M eanwhile the exodus from Sega contin- 
ues, with Chris Garske going to Good 
Times Software and Wayne 
Townsend, former head of Sega 
Sports, leaving to start his own develop- 
ment group. 



Got gossip? E-mailThe Gossip Lady at 

71501.3553@compuserve.com. 
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BIT BLASTS 



Kids ore People, Too 



Creators of children's edutainment will 
have the chance to connect with 3,000 of 
their potential customers ctober 5-8 at 
the second C hildren's M ultimedia Expo 
in San Francisco, Calif. The event, 
which debuted in June of 1995, will 
bring together thousands of kids, educa- 
tors, parents, retail buyers, and multime- 
dia pros for four days of show and tell. 
Edutainment developers will have the 
opportunity to gain important feedback 
on their products during demos and 
focus group testing with some 3,000 
children and teachers brought in from 
schools throughout California. (Wow 
kids, here's a field trip to a place where 
you can play computer games all day 
long— the only catch is you've got to 
answer a few questions from some 
friendly marketing executives....) Last 
year, multimedia companies demonstrat- 
ed works in progress as well as titles cur- 
rently shipping. 

Two days of the four-day event are 



closed to the general public. During the 
weekend, the doors open to everyone 
and special family-focused Internet and 
W orld W ide W eb demos and workshops 
will take place. At the end of the Expo, 
students and teachers will vote on their 
favorite titles in the K ids' C hoice and 
Teachers' C hoice A wards. 

Vendors exhibiting at the show are 
by invitation only. Companies interested 
in participating in this event or future 
Children's M ultimedia Expos must sub- 
mit their products for review. For more 
information, contact event producer 
Shannon Tobin at (415) 788-9990 or fax 
(415) 243-8939. ■ 

■ For more information contact: 
Shannon Tobin 
Event Producer 
Children's Multimedia Expo 
Tel: (415)788-9990 



N icole C laro is managing editor for 
Game Developer magazine. Barbara 
H anscomeis managing editor for Software 
Development magazine. 









UPGRADE 



YOURS! 



• Caligari's newest upgrade is 
trueSpace2 for Windows. It 
features new animation and 
video capabilities and true- 
Clips, a CD-ROM of more 
than 200 textures and 600 
three-dimensional objects. 
The upgrade is available to 
trueSpacel.O users for $149 
and $795 for new users. 

• Borland is shipping Turbo 
C++ 4.5, which includes five 
free games with full source 
code. This latest version is 
geared toward beginning 
programmers and retails for 
$79.95 for new users and 
$49.95 for owners of any 
previous versions of Turbo 
C++. 
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BEHIND THE SCREEN 



Memory 
Miscellanea 



Don't morrii. perspec- 
tive texture mapping is 
olive and well. But this 

month. Chris Hecher 
takes a break from his 
series on texture 
mapping to explore the 
nuances of 
memory banduiidth in 

game programming. 



Hs you can see from the title, 
this article is not "Perspective 
Texture M apping, Part IV," 
the continuation of our epic 
perspective texture mapping 
series. Don't panic, I'm not 
breaking my promise to deliv- 
er a wicked fast perspective 
texture mapper, but to break up the 
series a bit I thought I'd insert a non- 
texture mapping article here in the mid- 
dle (although the topic is definitely 
applicable to texture mapping, as you'll 
see). We'll resume with Part IV next 
issue. 

T his time through, we're going to 
discuss memory bandwidth. Plainly stat- 
ed, memory bandwidth is a measure of 
how much memory you can read and or 
write in a given amount of time. 

From that description, it should 
be clear that memory bandwidth 
affects every kind of game on every 
platform, from scrolling platform 
games on an 8-bit N intendo or Atari 
2600 system to high-end military sim- 
ulators that cost millions of dollars. 
M emory bandwidth governs how many 
sprites the hardware in the older con- 
soles can move around, and how many 
polygons can be textured per second in 
hardware on the newest machines or in 
software on the PC . 

In fact, an oft-cited goal of PC 
graphics programmers is to "get your 
texture mapper running at memory 
bandwidth," because there's not much 
more you can do to increase its speed 
after that. To get a tad flowery, memory 
bandwidth can be an open door or a 
brick wall. It all depends on how much 
of it you've got. 



Lies, Damn Lies, and 
Bandwidth Numbers 

On today's machines, we usually mea- 
sure memory bandwidth in megabytes 
per second (M Bis), but you'll sometimes 
see bytes per second, dwords (a dword is 
four bytes in this article) per second, and 
so on. If you're looking at a bunch of 
memory bandwidth numbers, it's obvi- 
ously important to know which measure- 
ment units they're in. 

Like most statistics, the bandwidth 
numbers themselves aren't enough to tell 
the whole story, and you need to know 
exactly how the numbers were generated 
for a specific machine to give them 
meaning. For example, I could tell you 
the laptop on which I 'm typing right now 
gets 42 M B/s, but you really aren't any 
more knowledgeable than before because 
you don't know if I mean read band- 
width, write bandwidth, copy bandwidth, 
sequential or random reads or writes, or 
any combination thereof. All these para- 
meters can make a big difference inwhat 
a bandwidth number really means. 

In fact, it's rare that any general 
bandwidth number will mean anything in 
the context of your specific game. I 'm 
going to talk about various things that can 
affect your game's memory bandwidth, 
techniques for measuring that bandwidth, 
and pitfalls you'll encounter along the way. 

Pyramid Power 

First, we need a one-minute refresher on 
how modern CPUs and motherboards 
work. I'm certainly no hardware engi- 
neer, so we'll limit our discussion to how 
the software sees the hardware. 

Throughout computer history, 
there's always been a pyramid diagram 
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that describes the speed of the compo- 
nent vs. how much of that component 
you're likely to have in your system (usu- 
ally because faster components are more 
expensive). Figure 1 shows this diagram 
for memory components. 

At the top of Figure 1 we have the 
C PU registers, which usually take a single 
cycle to access and are the most flexible of 
all types of memory, but are pretty scarce 
(I ntel x86 processors have only eight gen- 
eral purpose registers, each of which holds 
four bytes, while most new processors like 
the PowerPC have around 32— all the par- 
enthetical numbers in this paragraph are 
estimates and will vary in practice). Below 
the registers, we have the on-chip cache 
memory, sometimes called the level 1 
cache. T his is usually a small amount (8 to 
32KB or so) of fast memory with access 
times slightly slower than registers. Cache 
memory is a little less flexible than regis- 
ters, as well. M ost CPU architectures don't 
let you add a number in the cache directly 
to another number in the cache without 
using the registers for temporary storage. 

n the next rung down, we have the 
off-chip level 2 cache, which usually has 
more storage space (256KB to 1M B), but 
is much slower than the on-chip cache, 
generally on the order of five times slower 
or more. 



Second to last in our diagram, we 
have main memory— of which there's 
usually a relatively large amount (4 to 
32M B). As you'd expect, it's even slower 
than any of the memories above it. F inal- 
ly, we end up with the hard disk, which 
has oodles of storage (well, okay, my hard 
disk sometimes has less space free than I 
have main memory, but it still has more 
raw storage!) if you're willing to pay for 
the access time and transfer rates. CD- 
ROMs and tape drives would be below 
hard disks if we put them in the dia- 
grams, because they're cheaper (and 
slower) per megabyte. 

The most interesting thing about 
F igure 1 is that it holds for almost every 
machine architecture, from Commodore 
64s to C rays. n the lowest end, you 
might not have caches, and at the higher 
end you might have more layers, but the 
speed vs. cost ratios still stand. 

W ith that refresher, let's get to the 
hints, tips, and techniques for determin- 
ing the memory bandwidth for your 
game, so you can strive to achieve it. 

Whaf s Your 
Access Pattern? 

As I mentioned, a single number doesn't 
tell the whole story about memory band- 
width. In fact, there are zillions of differ- 



ent kinds of memory bandwidth, each 
different because the access pattern used 
to generate the numbers is different. T he 
access pattern is the way the application 
moves the memory around, and there are 
as many different types as there are pro- 
grams. Three general categories that are 
important, but by no means form a com- 
plete list, are sequential copy bandwidth, 
sequential write bandwidth, and random 
read- sequential write bandwidth. 

Sequential copy bandwidth is the 
number that applies when you're copying 
a block of memory from one place to 
another— to copy a new piece of digital 
audio into the play buffer, for example. 
Sequential write bandwidth is what you 
see when filling a rectangle or polygon, 
zeroing an array, or anything else where 
you're writing a single value or a value 
that's generated using instructions (as 
opposed to read from a source) to a desti- 
nation. Finally, random read-sequential 
write bandwidth is what you see when 
texture mapping, where your source loca- 
tions are fairly randomly distributed, but 
you're usually writing a scanline at a time 
to the destination. 

From these descriptions, you can 
easily come up with other kinds of band- 
widths and situations in which they'd 
arise. You might find multiple reads and 
a single write interesting if you're mixing 
digital audio or alpha blending sprites. 
Likewise, a single read and multiple 
writes might be your thing if you're 
stretching an image. The key is to figure 
out which type of bandwidth is most 
appropriate to your application and mea- 
sure it. 

It's clear that any useful and inter- 
esting application is going to do more 
than just copy bits all day, but memory 
bandwidth gives a good upper bound on 
your performance. I n other words, even 
if you were the best optimizer on earth, 
you still wouldn't be able to get your 
code faster than memory bandwidth if 
you need to move those bits around. 
This may seem like a limitation, and it 
is, but you can also look at it as an 
opportunity. If you can figure out a way 
to reduce your memory bandwidth 
requirements by redesigning your algo- 
rithm or possibly by changing your 
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access pattern you can open up new pos- 
sibilities for optimization. 

An Accessible Example 

For example, if you were writing a solid 
polygon rasterizer, you could measure 
sequential write bandwidth and compare 
it to the fill rate you get through your 
rasterizer. The difference is your over- 
head above memory bandwidth. Your 
goal is to minimize this overhead or, if 
possible, cheat somehow so you get the 
same effect on the screen but aren't 
bound by the same memory bandwidth 
limitations. 

L et's say you have the world's fastest 
90- degree bitmap rotator; you can take a 
bitmap and rotate it 90 degrees at memo- 
ry bandwidth on your machine— you're 
very proud of this code. You know it 
works at memory bandwidth because you 
measured it without any instructions 
except the copies in the inner loop and 
got the same bandwidth number when 
you added your rotator code. Let's also 
say your code is "destination-centric," 
that is, it scans horizontally in the desti- 
nation and therefore it scans vertically in 
the source to accomplish the rotation. Of 
course, you measured memory bandwidth 
doing the same thing, so let's call this 
access pattern vertical read- sequential 
write. Since we're running up against this 
memory bandwidth limitation, how can 
we restructure the algorithm to have a 
different limitation? 

It's immediately apparent that you 
should measure sequential read-vertical 
write, which will accomplish the same 
rotation, but might be a different speed. 
Also, another possibility is to spend a lit- 
tle memory and pre- rotate your bitmaps, 
so your access pattern is sequential copy. 
W ill either of these be faster? I don't 
know, and we can't say with certainty 
until we've timed it. M y hunch is that 
sequential copy will be the fastest in 
terms of pure bandwidth because it's 
probably the access pattern for which the 
memory subsystem was optimized, but 
it's just that, a hunch. It's entirely possi- 
ble the extra memory overhead from pre- 
rotated bitmaps would make the overall 
code slower because of paging. 

T he real solution, if this is a bottle- 



neck in your game's run-time speed (and 
you shouldn't even be bothering to mea- 
sure this stuff if it isn't a bottleneck), is to 



Mat's fastest on 
your machine 
might not be 
fastest on mine. 
The best we can 
do is have a list of 
things to look for 
uihen we're mea- 
suring bandwidth. 



profile the various techniques at startup 
and have your game self-configure to use 
the fastest possible pattern for the given 
machine. 

It may seem like I'm being wishy- 
washy by not just declaring a single 
access pattern the fastest, but we've got 
far too many variables to do so. T he 
problem is compounded by the number 
of different hardware architectures out 
there, so what's fastest on your machine 
might not be fastest on mine and vice 
versa. T he best we can do is have a list of 
things to look out for when we're mea- 



suring bandwidth. Cache effects would 
definitely be at the top of this list. 

Understand the Cache 

The processor cache is usually an object 
of great fear, wonder, and misunder- 
standing. A friend of mine named Terje 
M athisen says, "All programming can be 
thought of as an exercise in caching." 
Although Terje isn't talking specifically 
about the processor cache, this is a rule to 
live by when you're trying to optimize on 
modern processors. If we apply this idea 
to the processor cache and memory 
bandwidth, it means, "Figure out how to 
put your important data in the cache and 
keep it there." This may seem obvious, 
but keeping your data in the cache is 
more difficult than you might think. 

Before we bother getting into this, 
what difference does it make? Well, on 
my laptop, the speed difference between 
reading from the on-chip cache and 
reading from sequential uncached memo- 
ry is tenfold— and this isn't even the 
whole story. I'm reading sequentially in 
this example, so at least some of the reads 
are cached for reasons I 'II explain shortly. 
I f I ensure that all the reads are uncached 
by reading pseudo- randomly, the pro- 
gram reads from the cache about 30 
times faster than from main memory. 
You can do a lot in 30 cycles on a mod- 
ern processor, so I 'd rather not spend 
them waiting on memory. 

I'm going to assume you know gen- 
erally what a cache is and how it works, so 
the only high-level description I'll give is 
this: the cache stores frequently accessed 
data in fast on-chip memory, so when you 
reference it the chip doesn't have to go out 
to the memory bus to fetch your request. 

Caches are broken up into cache 
lines, which are usually 16 or 32 bytes 
long, and the processor reads in an entire 
cache line from memory when a cache 
miss occurs. T hese cache lines are aligned 
on address boundaries that correspond to 
their length, so 16-byte cache lines are 
aligned on 16-byte boundaries, for exam- 
ple (addresses ending in hexadecimal). 
T his is why my previous sequential reads 
were partially cached. Assuming a 16- 
byte cache line, every fourth dword I read 
in my test brought in another cache line, 
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and the next three dwords were read 
from the cache's fast memory. T he use of 
cache lines also means that if you're refer- 
encing two bytes at addresses that differ 
by more than a cache line (or if there's a 
cache line boundary between them) you'll 
be using two lines, even if you're only 
accessing those two bytes. 

L ife in the cache gets even worse 
when we delve deeper into its behavior. 
M ost modern caches are N - way set asso- 
ciative for some small integer N , usually 
2 or 4. A cache set is a group of N cache 
lines, so a two-way set associative cache 
has a bunch of sets, each containing two 
cache lines. You can tell how many sets 
there are by taking the size of the cache 
in bytes, dividing by the number of bytes 
per line to get the total number of lines, 
and then dividing by N for your cache to 
get the total number of sets. For example, 
the Pentium has 8KB of two-way set 
associative data cache with 32- byte cache 
lines, so 8KB / 32 bytes/ 2 lines per set = 
128 sets. 

The cache translates a memory 
address into a cache line address by using 
the lowest bits for the intra-line address, 
the next few bits for the set address, and 
the remaining high bits for the cache tag. 
Figure 2 shows the breakdown for the 
Pentium. Because there are 32 bytes in a 
cache line, the lower five bits are used for 
the intra- cache line address, and the next 
seven bits give us the 128 sets we calculat- 
ed previously. W hich line a given address 
uses in its set is up to a replacement algo- 
rithm (usually least recently used or an 
algorithm close to it) based on the cache 
tag bits. I n other words, every address 
that contains the same set address bits 
will map to the same set, and all those 
addresses must share the lines in that set. 

T his is where the replacement algo- 
rithm comes in. If all the lines in the set 
are currently full and none of the tags 
matches the requested address, then one 
of the currently cached lines needs to be 
replaced by the current requested line. 
For example, on the Pentium only two of 
the many possible cache lines (20 bits 
worth of lines because bits 12-31 make 
up the tag— that's 1,048,576 possible 
lines!) for a given set can be in the cache 
at the same time. 



You can see why this works well in 
the general case because referenced 
addresses are likely to be near each 
other— a phenomenon called locality of 
reference— so they'll have different set 
addresses. T he set architecture allows for 
some addresses to be not- so- near each 
other because it lets very different 
addresses with the same low bits map to 
N different cache lines (in contrast, a 
cache architecture called direct mapped 
has no sets, so each address with the 
same low bits shares a single cache line). 

H owever, in certain cases this kind of 
cache architecture can really screw you up. 
For example, let's say you're reading verti- 
cal strips from a bitmap like the bitmap 
rotator we discussed previously— down 
one vertical scanline, then down the next, 
and so on. T he width of your bitmap will 



dictate how much of the cache you end up 
using. If your bitmap is 256 bytes wide, a 
single increment vertically will step bit 8— 
and never any bits below bit 8— in your 
address. If you compare that with the 
Pentium's cache address layout in Figure 
2, you'll notice that you're only using four 
bits of your possible seven bits of set 
address. This means that instead of using 
all 128 sets, you're only using 16 of them 
or only 1/8 of your total cache! The star- 
tling implication of this is the next hori- 
zontal byte from the first scanline will not 
be in the cache when you get back up 
there if you've gone farther than 32 scan 
lines (16 setsx 2 lines per set) because it's 
been pushed out of its set by another line. 

Assume Nothing 

W hat can you do about this sort of 
thing? W ell, first you need to realize 



when it is happening in your code. To 
do this, you need to get good at profil- 
ing. Profiling at this level doesn't mean 
just running the code profiler that comes 
with your compiler and examining the 
results, it means figuring out exactly 
where your code is spending its time in 
the inner loop. You can definitely use 
the high level profiler to find the inner 
loop in the first place, but once you've 
found it, if you want to max it out and 
really pin down why it's taking the time 
it is, you're going to need to get down 
and dirty with a very accurate timer (per- 
sonally, I use timeGetTime or QueryPerfor- 
manceCounter on W indows, but any accu- 
rate timer will work) and a knowledge of 
assembly language. 

Before continuing I should stress 
that this kind of profiling and optimiza- 



tion takes a very long time, so you should 
make absolutely sure you're applying that 
time to the right part of your code. In a 
game, there are probably 10 lines of code 
in the entire project that might need this 
sort of attention, and if you're going to 
spend a week looking at them you had 
better make sure they're the right 10 lines. 

M ichael A brash's phrase, "Assume 
nothing!" and its corollary, 'Time every- 
thing," are words to live by in this neck of 
the woods. A brash is the master of this 
sort of optimizing, so you should defi nit- 
ley read his book Zen of Code Optimiza- 
tion (Coriolis, 1994). As a bonus, the 
disk that accopaniesthe book comes with 
a very accurate timer designed specifically 
for this in-depth profiling. 

W hile I was writing this column, 
the need for this very kind of profiling 
came up. I was gathering bandwidth 



Figure 2. Pentium Cache Addressing 



Address Bits 



31 12 


11 5 


4 








1 ntra- 


lino 






Set address 


addr 





20 GAME DEVELOPER • OCTOBER/NOVEM BER 1995 



statistics for various access patterns on 
my 486 laptop and I was trying to time 
cached reads. I know from both experi- 
ence and the 486 manual that a read 
from the cache is a single cycle, but I 
couldn't seem to convince my timing 
program of this fact. It kept returning 
around 1.5 cycles per read, and when 
you're timing at this level that's 50% 
off. M y test program had an unrolled 
loop of a couple of hundred reads, and 
then I looped back to the top a bunch 
of times. I was very careful not to 
unroll my loop so much that it blew out 
the code cache, so I simply couldn't 
figure out what was going on. I timed 
other single cycle instructions with the 
same timing harness (using a millisec- 
ond timer and looping a lot), and they 
returned reasonable times, like 1.02 
cycles, but my reads kept returning 1.5. 
If I stuck a nop in between the unrolled 
reads I got the expected two cycles, one 
for the read and one for the nop. I 
stared at the code, trying to find an 
address generation interlock, (A G I — 



I ntel-speak for a type of pipeline stall), 
but there weren't any. 

Finally it hit me. I remembered that 
if you're continuously reading from 
cached memory without allowing even a 
single free memory cycle for prefetching 
instructions, the 486 will stall your code 
to fill the prefetch queue. Eureka! I veri- 
fied this was the culprit by changing the 
number of consecutive reads and got the 
expected one cycle per read. I also looked 
it up in the 486 Programmer's Reference 
M anual from I ntel, and the stall was list- 
ed there among the others. 

Time to Cache Out 

As you can see, figuring out where every 
cycle is going in your inner loop, espe- 
cially when there are strange effects 
brought on by your memory access pat- 
tern, is very difficult and time consum- 
ing. I highly recommend reading and 
rereading the manual for your processor 
before you try to do this. Also, always 
test your timing program with known 
inputs so you can verify that it works; 



H eisenberg is alive and well at this level. 

I haven't covered video memory and 
its associated bandwidth weirdnesses at 
all. N or have I discussed processor write 
buffers, write- back versus write-through 
caches, processors that don't write allocate 
cache lines (like the Pentium), new trends 
in memory that affect the bandwidth 
numbers (like EDO memory, RAM BUS, 
and SDRAM ), groovy new cache/access 
pattern debugging instructions (like 
RD M SR on the Pentium), and much 
more. H opefully this article gives you 
enough background and forewarning 
about the strangeness you'll encounter 
that when it's time to max out your inner 
loop, memory bandwidth won't be the 
mystery it can be for the unprepared. ■ 



Chris H ecker wonders why five-year- 
old workstations with incredibly slow 
CPUS still have better memory bandwidth 
than today's top- of- the- line PCs. You can 
commiseratewith him at checker@bix.com. 
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Most programs I Ve written have 
required some form of input 
from the user. I n most cases, 
the programming language or 
the library provided with the 
language was sufficient to get 
the input in a reasonable 
manner. Of course, none of 
these programs was a game. 

Fast action games need to process 
multiple, simultaneous key presses at a 
frantic rate. M ost fighting games provide 
combinations of keystrokes that, when 
pressed within a limited timeframe, cause 
some special move to be executed. N ot to 
mention the mouse and joystick, other 
common game input devices that aren't 
even supported by most compiler libraries 
The question is, how can we obtain the 
user's input in a reasonably efficient and 
general manner? 

The input queue manager presented 
in this article is my solution to this prob- 
lem. This manager accepts the raw input 



from the hardware devices and stores each 
input as an event on an internally main- 
tained queue. W hen a client program 
requests input, the oldest event is returned. 

The main design goals for the input 
queue manager were: 

• Gather user input asynchronously to the 
client program 

• M inimize memory and execution over- 
head 

• Return user input in a single format 
regard I ess of the i n put devi ce. 

I developed the input queue manager 
in C and assembly language using ancient 
versions of Borland C/C++ and Turbo 
Assembler, though I've now converted 
most of the assembly language to C for the 
sake of maintenance. 

The Input Queue 
Manager Structure 

Figure 1 is a block diagram of the input 
queue manager. T he keyboard, mouse, and 
timer generate interrupts when they are in 
need of service. The input queue manager 
handles these interrupts, storing the infor- 
mation gathered on an internal queue and 
supplying that information to the client 
program, on request, as events I n addition, 
the client program may post events to the 
input queue if required. T he mouse cursor 
interface allows the event manager to 
accept mouse events even if the video 
mode isn't supported by the default mouse 
driver (as in M odeX and VESA). 

"W hy no joystick handler?" you may 
ask. The input queue manager only han- 
dles events that can be gathered via inter- 
rupt. ne of my design goals was to pro- 
vide as little overhead to the client program 
as possible. The joystick has to be polled at 
regular intervals for its current position and 
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button state, so I chose not to make joy- 
stick support intrinsic to the design. 

Using the Input 
Queue Manager 

Before digging into the nuts and bolts of 
the input queue manager, I'll present a 
simple example of its use to give you a feel- 
ing for the interface. This example exits 
after the escape key is pressed. Pressing any 
other key causes that key's A SC 1 1 value to 
be printed. L isting 1 contains the code for 
the example. 

You must include the header file, 
inputq.h, at the top of all source files that 
make use of the input queue manager. 
This file defines the input queue manager's 
data structures and provides prototypes for 
all its visible functions, the names of which 
are prefaced with dipq_. 

T he first call to the input queue man- 
ager is lNPQ_allocate(). This routine allo- 
cates all required events and a correspond- 
ing queue large enough to hold them. T he 
number of events to allocate is supplied as 
an input parameter to the call. 

N ext, we enable key press events with 
a call to DJPQ_enable_keyboardO. This rou- 
tine installs a keyboard interrupt handler 
and tells it to notify us every time a key is 
pressed. 

At this point, every key pressed will 
enqueue an event. These events will sit 
patiently on the input queue until the 
client program makes a call to 
DIPQ.dequeueO. 

DIPQ.dequeueO is implemented like 
the standard C library timeO routine. If no 
events are on the queue, NULL is returned. If 
there is an event, a pointer to the event is 
returned. If an event structure is passed 
into DIPQ.dequeueO, it will be used as the 



repository for the event, and its pointer will 
be the return value. Otherwise, an event 
structure internal to the input queue man- 
ager will be used. This structure is only 
valid until the next call to DIPQ.dequeueO 
with a NULL event parameter. 

When DIPQ.dequeueO is called, the 
next event matching the supplied event 
mask, key.doun in this case, will be 
removed from the input queue and 
returned to the client program. 

In our example, if the event is valid, it 
will be checked to determine if the key 
pressed was the escape key. If it is, we 
break out of the input gathering loop. 
Otherwise, the ASCII value of the key is 
printed. 

Finally, INPQ.releaseO is called to 
deallocate memory held by the input queue 
manager and restore the vectors of all 
interrupts that had been taken over. This 
call is just a formality, though. Because the 
execution of this routine is critical to the 
continued operation of the machine after 
the client program terminates, DJPQ.allo- 
cateO installs it as an exit handler. So, 
while calling this routine is a good practice, 
it's not absolutely necessary. 

This is all I'm going to say for 
now about the visible interface to the 
input queue manager. These functions, 
along with the functions to enable the 
mouse and timer handlers, make up the 
crux of the interface. Table 1 contains a 
list of all visible input queue manager 
functions. 

The Event Structure 

Figure 2 is a graphical representation of 
the event structure. Listing 2 shows the 
actual type definitions. Each event is iden- 
tified by its type field, which contains a 



Mike Michaels 

Fire kens, kei| 
combinations, timed 
hey combinations... 
What's a programmer 
to do? Create a 
single, high-perfor- 
mance inpot 
manager, that's 
what! 
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Listing 1. Input Queue Manager 



((include <stdio.h> 
#include "inputq.h" 
int main (void) 

{ 

EVENT event; 

if (!INPQ_allocate (32) 1 1 
!INPQ_enable_keyboard (key.down)) 

{ 

printf ("Unable to initialize \ 

input queue manager. \n"); 
exit (1); 

} 

for (;;) 
{ 

if (INPQ_dequeue (itevent, key_down)) 
{ 

if (event. data. kbd.scancode = 
ky.ESC) 

break; 
printf ("7,c\n", 

INPQ.ascii (ievent)); 

} 

} 

INPQ.release (); 

} 



unique binary value depending upon the 
event in question. T he values are assigned 
from the EVENT_TYPE enumeration defined 
in Listing 2. 

Each event type has some unique 
information assoicated with it. This infor- 
mation is stored in the event's data field. 
The information returned by keyboard 
events, for example, is the scan code of the 
key that was pressed or released. T he 
information associated with some events 
may not be complete without additional 
context information. This information is 
stored in the attributes field. Scan codes do 
not take into account the state of the shift, 
Ctrl, and alt keys T hese keys must be reg- 
istered by the keyboard handler and their 
state passed along in the attributes field of 
the event. 

Finally, each event contains a time- 
stamp obtained from the C M S clock at 
the time the event is queued. The time- 
stamp serves two purposes. First, it allows 
the input queue manager to properly 
order events internally (we'll discuss this 
in more detail in a subsequent section). 
Second, it allows the client program to 
determine the span between two or more 
events, a la the fighting game example 
mentioned previously. 

E ach of the event types and their cor- 



responding data and attributes will be 
discussed more thoroughly when we 
are discussing specific event types. For 
the time being, let's move on to look at 
the data structure on which the input 
queue is based, the priority queue. 

Priority Queue Concepts 

The client program isn't necessarily 
going to process events as soon as 
they are available, so some sort of 
queue is required. A priority queue 
data structure was chosen for a num- 
ber of reasons. 

The priority queue structure 
allows events to be processed effi- 
ciently, in order or according to event 



type. Read "efficiently" as "in reasonable 
time." Pull out those data structures 
books and dust them off: a priority queue 
is a data structure that supports insertion 
of new prioritized elements and deletion 
of the element with the smallest (or 
largest) priority. 

The priority queue structure can be 
implemented to require a fixed memory 
overhead. I n other words, all memory for 
events and support structures can be preal- 
located when the input queue manager is 
initialized. This precludes the input queue 
manager allocating and freeing memory as 
events are processed, eliminating the risk 
of the input queue manager causing mem- 
ory fragmentation. 



Table 1. Input Queue Manager API 


Input Queue Control Functions 


TNDfl all nr-ifcM 
111 r 4_aJ_LOCaT.c V ) 


Initiali70c t"ho inniit" niiono mananor 
Mil Lla IIZ.tr b LI 1 c IlipUL LjUcUc llldl ldyt!l . 


INPq.releaseO 


C leans up after the input queue manager. 


INPQ.enable.keyboardO 


Enable keyboard events. 


TWpn Hicahlp kpvhnardf) 


Dfcahlp kpvhnarrl pvpnK 

lvijquic ixcyuuaiu cvciiij. 


INPQ_enable_mouse() 


Enable mouse events. 


IN PQ_disable_mouse ( ) 


Disable mouse events. 


INPq.enable.timerO 


Enable timer events. 


IN PQ_disable_timer ( ) 


Disable timer events. 


INPQ_enable_user() 


Enable user-defined events. 


INPQjJisable.userO 


Disable user-defined events. 


INPQ_events_enabled() 


Return enable events. 


Queue Management Functions 




INPQ_dequeue() 


Dequeue an event, based upon event type. 


INPQ_enqueue() 


Enqueue an event, possibly user defined. 


Keyboard Support Functions 




INPq.ascii() 


Translate a scan code to its ASCII equivalent. 


Mouse Support Functions 




INPQ.showjnouseQ 


Show the mouse cursor. 


INPQ_hide_mouse() 


Hide the mouse cursor. 


IN PQ_mouse . visible ( ) 


Return true if the mouse is currently visible. 


INPQ.obscurejnouseO 


Hide mouse cursor without affecting events. 


INPQ.unobscurejnouseO 


Show mouse cursor without affecting events. 


INPQ_set_graphics_cursor_shape() 


Set the mouse cursor shape. 


INPQ.setjnouse.position () 


Reposition mouse to new coordinates. 


INPQ_get_mouse_position() 


Return mouse's current coordinates. 


INPQ_push_mouse_regions() 


Prepare to define hots pots. 


IN PQ.def ine_mouse_ region ( ) 


Define a hotspot. 


INPQ_pop_mouse_regions ( ) 


Discard mouse regions. 


Timer Support Functions 




INPQ_set_alarm() 


Enable one of 16 countdown timer alarms. 



24 GAME DEVELOPER - OCTOBER/NOVEMBER 1995 



Listing 2. Excerpts from IN PUTQ.H 



((include "basic.dt.h" 
((include "scancode.h" 



#define LAST.ALARH 15 



typedef enum { 




null_event 


= 0x0000, 


key.down 


= 0x0001, 


key_up 


= 0x0002, 


mouse_down 


= 0x0004, 


mouse.up 


= 0x0008, 


mouse.move 


= 0x0010, 


timer.alarm 


= 0x0020, 


first.usr 


= 0x0040, 


last_usr 


= 0x8000 


} EVENT.IHSK; 





/* 

** Attributes Structures 
*/ 

typedef struct { 

ul6 k.extended 

ul6 k.shift 

ul6 k.ctrl 

ul6 k_alt 

ul6 k.unused 
} KEYBOARD. SHR; 



typedef struct { 

ul6 m.region : 8 

ul6 m.left : 1 

ul6 m.right : : 1 

ul6 m.center : 1 

ul6 m.unused : 5 

} M0USE.ATTR; 

typedef union { 

KEYBOARD. ATTR kbd; 

HOUSE.ATTR mouse; 

ul6 value; 
} INPQATTR; 

/* 

** Data Structures 
*/ 

typedef struct { 

u8 scancode; 

u8 reservedl; 

ul6 reserved2; 
} KEYBOARD.DATA; 

typedef struct { 

sl6 x; 

sl6 y; 
} MOUSE.DATA; 

typedef struct { 

u8 alarm; 

u8 reservedl; 

ul6 reserved2; 
} TIMER.DATA; 

typedef union { 

KEYBOARD.DATA kbd; 
MOUSE.DATA mouse; 
TIMER.DATA timer; 
s32 value; 



} INPQDATA; 



** Event structure 
*/ 

typedef struct { 

u32 timestamp; 

ul6 type; 

INPQATTR attr; 

INPQDATA data; 
} EVENT; 



Our priority queue implementation 
will be based upon a specific type of binary 
tree data structure known as a heap. A 
heap is a binary tree that satisfies the heap 
condition: the priority of any given node is 
less than or equal to the priorities of the 
node's children (if they exist). T his condi- 
tion can easily be encapsulated in an array 
representation, as shown in Figure 3. 

Assume that the values within the 
nodes are the priorities It is trivial to verify 
that every node in this tree satisfies the 
heap condition, and therefore this tree is a 



Figure 2. Event Structure 
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of the node located at position 7 is 
(int)(7/2) =3. 

G iven that we can find the parent 
and children of any node regardless of its 
location on the heap, how do we perform 
insertion and deletion operations? Listing 
3 contains the heap manager code, includ- 
ing code to perform insertion (enqueue) 
and deletion (dequeue) operations on the 
heap. 

To insert an element into a heap, we 
see that the enqueueO function starts by 
inserting the new element at the end of the 
array. This corresponds to placing the new 
element at the bottom of the heap. At this 
point, we may not even have a heap any- 
more, because the heap condition may be 
violated at this terminal position. T he rou- 
tine reorder_heap() is called to fix any vio- 
lations of the heap condition. It does this 
by checking the priority of the newly 
inserted event against the priority of its 
parent. If the parent priority is larger, the 
two events are swapped. This continues 
until the new event can no longer be 
swapped with its parent, resulting in a tree 





heap. N ow we can convert this tree repre- 
sentation into an array representation by 
simply starting at the root of the tree and 
adding elements to the array in a top-to- 
bottom, left- to- right, fashion (a breadth- 
first traversal if you will). 

W ithin the array, the children for any 
node, say the node at position k, are locat- 
ed at positions 2k and 2k+l. This in turn 
implies that the parent of any node, say the 
node at position j, can be found at position 
(int)(j/2). For example, in Figure 2, the 
children of the node located at position 3 
are located at positions 2*3=6 and 2*3 + 
1=7 respectively. Conversely, the parent 



that satisfies the heap condition. 

Deleting an element from the queue 
is just slightly more complicated. The 
dequeueQ operation first deallocates the 
event to be deleted, returning it to the pool 
of available events. Then, the event at the 
last array index in the heap is inserted in 
the position of the deleted event. Again, 
we may no longer have a valid heap, since 
the event we just inserted has an arbitrary 
priority. The reorder_heap() routine is 
again called to restore the heap to a valid 
state. 

T his time though, reorder.heapO 
must try and work the inserted event down 
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Figure 3. Conversion of a Heap Represented as a Tree into an Array 
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the heap until the heap condition is satis- 
fied. It does this by checking the children 
of the newly inserted event. If no children 
exist, the heap condition is satisfied, and 
the routine is done. 

If children exist, the newly inserted 
event's priority is checked against the 
largest of its children's priorities. If the 
newly inserted event's priority is greater, it 
and the larger child are swapped. This 
continues until there are no more children 
to check (at which point the event is at the 
bottom level of the heap) or the event's 
priority is less than both of its children's 
priorities, satisfying the heap condition. 

The final operation we want the pri- 
ority queue to perform is a search for an 
arbitrary element. The routines 
locate_event() and find_event() work 
together to perform a recursive binary 
search of the heap based upon an event 
type. I used a recursive search because it 
was easy— I didn't anticipate a burgeoning 
heap and I was getting lazy. N eedless to 
say, a better implementation would use a 
state variable and a loop to remove the 
dangers associated with the recursion. 

Both the insertion and deletion oper- 
ations can be performed in time propor- 
tional to (In N ). T he binary search oper- 
ation, for an arbitrary value, can be per- 
formed in time proportional to 0(2ln N) 
on average, with a worst case time propor- 
tional toO(N). 

To provide some basis for compari- 
son, consider implementing the priority 
queue with a standard, albeit modified, 
queue structure. Insertion would require 
nothing more than adding a new element 
to the end of the queue (remember, we 



want to delete items with the smallest pri- 
orities). Assuming we keep a pointer to the 
tail of the queue, this operation can be per- 
formed in constant time (0(1)). Deleting 
the element with the smallest priority is 
also trivial: just remove the element at the 
head of the list. Again, this is a constant 
time operation. But if you want to find an 
arbitrary element, searching the queue is 
going to take time proportional to O (N ) 
on average. 

The heap implementation takes 
slightly longer to insert and delete ele- 
ments, because it must maintain the 



cated, events are stored in a pool, which is 
managed by theallocate_event() and deal- 
locate_event() routines. 

Allocate.eventQ is called from our 
event handlers when input is received. If 
there is an event to return, the C M O S 
timer function, GetTickCount (also shown in 
Table 2) is consulted and its current value 
is stored in the timestamp field of the 
event. 

The timestamp value is important in 
two ways First and foremost, it is used to 
order the input queue. T he queue is 
ordered from smallest timestamp (oldest 



Table 2. CMOS Get lick Count Function 



Int 1AH Function 00H 
Get Tick Count 

Returns with the contents of the clock tick counter. 

Call with: 

AH = 00H 

Returns: 

AL = rolled-over flag 

00H if midnight not passed since last read 
<> 00H if midnight passed since last read 

CX :DX = tick count (high 16 bits in CX) 



heap condition, but when searching for 
arbitrary elements, it is significantly 
faster on average than the standard 
queue implementation. 

The Event Pool 

As I mentioned previously, iNPQ.allocateO 
and INPQ_release(), shown in Listing 4, 
work together to allocate and free memory 
for events and the input queue. O nee allo- 



event) to largest timestamp (newest event). 
All queued events have nonzero timestamp 
values, so this field is also used as a free 
indicator in the event pool. A ny event with 
a zero timestamp cannot possibly reside on 
the input queue and is therefore available 
for allocation. 

Before it returns the address of the 
new event to its caller, allocate_event() 
enqueues the event. The only responsi- 
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bility the caller has is to fill in the event 
type, data, and attributes fields. Deaiio- 
cate_event() does little more than reset 
the timestamp of the supplied event to 
zero, freeing it for later use. 

Taking Control 
of the Keyboard 

Now that we can allocate and deallocate 
events, we're ready to start talking about 
populating the queue. The input queue 
manager has three event handlers— one 
each for the keyboard, the system timer, 
and the mouse. T he event handlers for the 
keyboard and the system timer both grab 
interrupt vectors and install interrupt ser- 
vice routines to gain control of all input 
from the given device. The mouse handler 
is slightly different. It makes use of the 
existing mouse device driver for its event 
notification. 

T he final topic we're going to discuss 
is the keyboard event handler. W e'll cover 
the timer and mouse event handlers in the 
second part of this series 

ThelBM PC keyboard communi- 
cates with the PC BIOS via hardware 
interrupt 09h. W henever a key is pressed or 
released, an interrupt 09h is generated and 
in most cases, the scan code of the key 
pressed can be read from the keyboard port 
located at address 60h. 

Certain keys generate extended scan 
codes. A key that generates an extended 
scan code requires the keyboard handler to 
processes two or more interrupts for the 
single key. On the first interrupt, the 
extended scan code identifier, OEOh, is read 
from the keyboard port. T he actual scan 
code may be read from the keyboard port 
on the next interrupt. 

I n most cases, extended scan codes 
are used when there are multiple identical 
keys on the keyboard. F or example, the Ctrl 
key on the lefthand side of the keyboard 
returns a standard scan code, and the one 
on the right returns the same scan code 
value, but as an extended scan code combi- 
nation. 

Some keys, such as print screen/sys- 
tem request and pause/break, generate 
multiple extended scan code sequences. 
T he simple keyboard handler we're devel- 
oping will not look for these, though this 
will not really be a problem. Each subse- 



quence is an extended scan 
code sequence; a single key- 
stroke generates multiple 
events 

ur keyboard handler 
will perform the following 
functions: 

• Obtain the scan code for 
the keystroke (taking into 
account the extended scan 
code behavior) 

• Acknowledge to the hard- 
ware that the interrupt was 
received and handled 

• T rack the current state of 
the shift, ctrl, and alt keys 
(the keyboard handler does 
not differentiate between 
left and right instances of 
these keys) 

• If appropriate, allocate an 
event and fill in the current 
attributes and scan code 
values. 



Listing 4. Excerpts from IN PUTQ.C 



BOOLEAN INPQ.allocate (sl6 n) 
{ 

if (n <= 0) 

n = DEFAULT_QUEUE_DEPTH ; 

pool = (EVENT *) caUoc (n, sizeof (EVENT)); 
if (!pool) 

return False; 
pool.last = n - 1; 
pool_first_f ree = 0; 



queue = (EVENT **) calloc (n + 1, 

if (Iqueue) 

{ 

free (pool); 
pool = NULL; 
return False; 

} 

queuejnax = n; 
queue.last = 0; 

atexit (INPQ.release) ; 
return True; 



sizeof (EVENT **)); 



} 



void INPQ.release (void) 
{ 

INPQ_disable_keyboard (events.enabled); 
INPQ.disable.mouse (events.enabled) ; 
INPQ.disable.timer (events.enabled) ; 



} 



Keyboard Events 

Figure 4 is a graphical repre- 
sentation of a keyboard event. 
T he event type field will 
either have bit 1 or bit 2 set to 
indicate a key_doun or key_up 

event, respectively. T he attrib- 
utes field contains bit flags 
indicating whether the event 
was obtained as a result of an 
extended scan code as well as 
the state of the shift, ctrl, and 
alt keys at the time that the 
event was generated. Finally, 
the data field contains the 
actual scan code received. 

You might ask why the 
A SC 1 1 code for the key isn't 
stored in the event as well. 
riginally, it was, and the 
event handler was spending 
most of its time doing the 
scan code to A SC 1 1 value 
translation. Because of the 
overhead and because each 
key is uniquely identified by its scan code, I 
made an executive decision to perform the 
ASCII translation outside the interrupt 
and only at the request of the client pro- 
gram. This method offers one more 



if (queue) 

{ 

free (queue); 
queue = NULL; 



(pool) 

free (pool); 
pool = NULL 



} 

BOOLEAN INPQ.enable.keyboard (EVENTJASK keyboard.events) 
{ 

keyboard.events &= (key.down I key.up); 
if (keyboard.events) 
{ 

initialize.keyboard (); 
events.enabled |= keyboard.events; 

} 

return True; 

} 

void INPQ.disable.keyboard (EVENTJASK keyboard.events) 
{ 

keyboard.events &= (key.down I keyjjp); 
events.enabled !f "keyboard.events; 
if (! (events.enabled & (key.down I key.up))) 
release.keyboard (); 

} 



advantage: if an ASCII value is never 
requested (via a call to iNPQ.asciiO), the 
code to perform the translation (and the 
substantial translation tables) never get 
linked into the client program's executable. 



GAM E DEVELOPER • OCTOBER/NOVEM BER 1995 27 



ORGANIZING USER 



The Keyboard Event Handler 

Listing 5 contains the code for the key- 
board event handler. T he first two routines 
are used to initialize and release the key- 
board interrupt, respectively. The key- 
board_events() routine, as the name 
implies, gathers keyboard events and 
returns them on the input queue. 

The first thing that keyboard_events() 
does is grab the byte from the keyboard 
port and clear the interrupt controller: 



Listing 5. KBD.C 



static void interrupt (*oldint9h)(void) = NULL; 
static ul6 static.attributes = 0; 

BOOLEAN initialize.keyboard (void) 
{ 

if (!oldint9h) 
{ 

oldint9h = getvect (KBD_INT) ; 
setvect (KBD.INT, keyboard.events); 
return True; 

} 

return False; 

} 

void release.keyboard (void) 
{ 

if (oldint9h) 
{ 

setvect (KBD.INT, oldint9h); 
oldint9h = NULL; 

} 

} 

static void interrupt keyboard.events (void) 
{ 

register u8 scancode; 
ul6 evtjnask = 0; 

scancode = inp (KEYB0ARD.P0RT); 

// acknowledge.interrupt 

outp (PIC.REGISTER, N0NSPECIFIC_E0I) ; 

if (scancode == EXTENDED_SCAN_CODE) 
{ 

static.attributes |= NOD.EXTENDED; 
return; 

} 

// assume key down event, modify if we 
// find out otherwise, 
evtjnask |= key_down; 
if (scancode & 0x80) 
evtjnask «= 1; 

// clear key up flag in scancode 
scancode 8i= 0x7F; 

if (evtjnask ti key.down) 
{ 

// key press modifiers 
switch (scancode) { 

case ky.CTRL : 



scancode = inp (KEYBOARD.PORT) ; 
outp (PIC.REGISTER, 
NONSPECIFIC.EOI); 

// acknowledge.interrupt 

The interrupt controller must be 
cleared because interrupt 09h is a hardware 
interrupt. It is actually attached to a line on 
the programmable interrupt controller 
(PIC). W henever the PIC generates an 
interrupt, that interrupt is masked off until 



static.attributes |= H0D_CTRL; 
break; 

case ky_ALT : 

static jsttributes |= NOD.ALT; 
break; 

case ky.LEFT.SHIFT : 
case ky_RIGHT_SHIFT : 
static jsttributes | = 

MOD.SHIFT; 

break; 
default 
break; 

} 

} 

else 
{ 

// key release modifiers 
switch (scancode) { 

case ky.CTRL : 
staticjsttributes &= 

"MOD.CTRL; 

break; 

case ky_ALT : 

staticjsttributes &= "MOD.ALT; 
break; 

case ky.LEFT.SHIFT : 
case ky.RIGHT.SHIFT : 
static.attributes &= 

"HOD.SHIFT; 

break; 
default 
break; 

} 

} 

if (events.enabled & evt.mask) 
{ 

EVENT *event = allocate.event (); 

if (event) 
{ 

event->event_mask = evt.mask; 
event->data. value = scancode; 
event->attributes. value = 
static.attributes ; 

} 

else 

++lost_input; 

} 

static.attributes ft= "MOD.EXTENDED; 

} 



the handler informs it that the interrupt 
has been noticed. The interrupt is 
acknowledged by outputting a value of 
0x20 (nonspecific EO I) to the PIC control 
port at address 0x20. 

Originally, this operation was per- 
formed at the end of the interrupt handler, 
which I consider a much safer place for it. 
B ut as soon as I had the debugger stop on 
a breakpoint within the keyboard handler, 
the machine would hang, and no further 
keyboard input was possible. This was 
. because the PIC refused to allow any 
more keyboard interrupts to occur until 
it saw an EOI for the current interrupt. 
But I couldn't make the debugger con- 
tinue to the point of the EOI until I 
could use the keyboard again (a frustrat- 
ing catch-22). 

After the interrupt has been 
acknowledged, the scan code is checked 
against the extended scan code. If it 
matches, we record the fact and exit the 
handler, knowing that the next interrupt 
we receive will contain the actual scan 
code. 

If the scan code isn't the extended 
scan code, the handler determines the 
event type (key.down or key.up) and the 
state of the special keys (shift, Ctrl, and 
alt). T his is all the information we need 
to generate an event. But we only gener- 
ate an event if the current event type 
matches one of the currently enabled 
event types 

If the input queue manager is 
enabled for the event that's been 
received, an event structure is allocated 
with a call to allocate_event(), and the 
keyboard attributes and data fields are 
filled in. If the input queue is full (all 
events have been allocated, but the user 
hasn't dequeued any at the time we want 
to post an event), we increment the 
lost.input variable. This variable isn't 
currently looked at anywhere, but I fig- 
ured that eventually, it might be a useful 
debugging aid. 

Where We're Going 

T hat does it for now. W e've covered the 
basic input queue manager, the event 
structures, and how keyboards events are 
actually generated. Next time, we'll dis- 
cuss user- defined events, timer events, 
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Figure 4. Keyboard Event Structure 




and mouse events. W ell also go into the 
mouse cursor interface, which will allow us 
to self-draw the mouse cursor in any video 
mode. 

Because of space limitations inherent 
in a magazine format, there is no way that 
the entire source for the input queue man- 
ager could be included with this article. 
Further, most of the comments were 
stripped out of the source that is included. 
Therefore, I encourage you to download 
the full source from theGameD eveloper ftp 
site (ftp://ftp.mfi.com/pub/gamedev/ 
src) or on C ompuServe SDFORUM 's 
Game Developer library. If you don't have 
access to either of these resources, but you 



do have an e-mail address, I 'd be happy to 
e-mail a uuencoded version of the sources 
to you. Just send mail to inpq- 
source@irvine.com with a subject line of 
"inpq source." ■ 



M ikeM i chads i s a senior softwareengi- 
neer with Irvine Compiler Corp., a small 
company that produces AD A compilers Yes, he 
realizes that Ada isdead. No, he doesn't write 
gamesin Ada. You ran contact him via email 
at mike@irvinecom. 
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XSplat: A Foundation 
for Cross- Platform 
Development 



Figure 1. The XSplat generic game architecture 
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TheUC Theatre in Berkeley, 
Calif, plays kung fu double fea- 
tures every Thursday. Recently, I 
had the pleasure of catching 
Twin Dragons, in which Jackie 
Chan plays twin brothers acci- 
dentally separated at birth in 
H ong Kong. ne moves to the 
U.S. with his wealthy parents, studies at 
posh New York private schools, and 
grows up to be an acclaimed piano player 
with very refined tastes. The other is 
found by a prostitute and grows up on 
the streets of H ong Kong to become an 
expert fighter. Neither brother knows of 
the other's existence. 

Eventually, of course, the brothers 
meet. T hey become fast friends and learn 
to take advantage of their identical 
appearances for maximum comic effect. 
The kung fu master receives a standing 



ovation for his passionate performance as 
conductor of a major orchestra, and the 
musician brother helps to defeat the 
forces of a major organized crime boss. 
All the while, Jackie Chan pulls off plen- 
ty of the insane gymnastic stunts that 
make his movies so painfully enjoyable. 

The "twins separated at birth" plot 
is awfully predictable. E very few years we 
see a new interpretation. I'm quite sure 
you've caught a few choice scenes from 
the 90s courtroom remake, Apple vs. 
M i trosoft. 

Separated at Birth 

I would gladly bet that for the last several 
years, Microsoft and Apple have 
employed more lawyers, clerks, judges, 
witnesses, paralegals, stenographers, and 
pizza makers while arguing over their 
claims and counterclaims than there are 
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middle managers at IBM . The Battle of 
the perating Systems rages between the 
twin children of Xerox PARC as they 
struggle over the look and feel of modern 
GUI computing. 

A s the distance between A pple and 
M icrosoft shrinks, each begins to exert a 
strange influence on the other. W indows 
95 introduces an integrated desktop 
metaphor, complete with a drag-and- 
drop recycling bin, plug-and-play, long 
filenames, and shortcuts to programs and 
documents. In Copland (MacOS 96?), 
A pple promises a true kernel- based oper- 
ating system with a device driver layer, 
protected memory, and user interface ele- 
ments such as the ability to minimize 
windows or gather them in "trays" at the 
bottom of the screen. 

All this belies the secret truth it's 
taken hundreds of lawyers to obscure: 
W indows and the M acintosh operating 
system are identical twins, born of the 
same womb and separated at birth. 
QuickTime, meet Video for Windows. 
Q uickD raw, G D 1 . penD oc, OLE. 
Component, DLL. PPC, DDE. What's 
the ultimate difference? A s programmers, 
we can create a single lollipop that will 
make both twin babies happy. 

I'm being naive on purpose to make 
a point: games generally bypass a large 
portion of the operating system in favor 
of algorithms specific to their application. 
Show me a system capable of displaying 
256- color palletized images and handling 
user input via a mouse and keyboard, and 
I 'II show you an ideal platform for today's 
games and most of tomorrow's. T ack on a 
rich set of standard system services such 
as event management, a 32- bit flat mem- 
ory model, a heap manager, and a file I/O 



system, throw in a 98% combined market 
share, and almost any game programmer 
will be in heaven. 

In this five-part series, I'll explore 
and develop a simple, reusable, platform- 
independent, GUI-based game library 
for the M acintosh and W indows that 
gives us something close to this ideal sys- 
tem. For historical reasons, I've chosen to 
call thissmall library XSplat. 

T his is actually the second article of 
the series, which I began with "A C++ 
Class for C ross- Platform Double 
Buffered Graphics" (June/July 1995). 
Subsequent articles will continue to build 
on each other until we have created a 
full-fledged playable game whose core 
code has been written for XSplat and 
compiles for M acintosh and W indows 
with no additional effort. The game 
won't be a cutting- edge mega- technolog- 
ical hit, but it will be a full-featured one 
that (I have high hopes) will be fun and 
playable. 

Developing a complete cross- plat- 
form game library involves a lot of code. 
G enerally, there will be more code asso- 
ciated with these articles than we can 
print here, but you'll find complete 
source code and compiled executables on 
the Game Developer ftp site, 
ftp://ftp.mfi.com/pub/gamedev/src/, in 
the /xsplat directory. All code will com- 
pile on the M acintosh using M etrowerks 
C/C -H-and on W indows using M icrosoft 
Visual C++ v. 2.1. 

The System Speaks 

T he most significant feature of any stan- 
dard W indows/M ac application is a loop 
that waits for the operating system to 
percolate events up from the user. W hen 
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With operating 
systems becoming 
increasingly, similar, 
complete cross-plat- 
form development is 
essential. In the first 
of a five-part series. 
Jon Blossom lays the 
groundwork with a 
library called XSPLAT. 
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Listing 1. XSplat Windowing and Messaging System Declaration 



class CXSplatWindou 
{ 

public: 

CXSplatWindou(char const *Caption, int WindouWidth=0, 

int WindouHeight=0, unsigned char const *Colors = 0); 
"CXSplatWindou(void) ; 



void Activate(void); 

void Deactivate(void); 

void Terminate(void); 

void KeyDoun(char Key, int RepeatCount) ; 



void MouseDoun(int x, int y); 
void MouseUp(int x, int y); 
void MouseMove(int x, int y); 

COffscreenBuffer *GetOffscreenBuffer(void) 
{ return pOffscreenBuffer; }; 



protected: 

int IsActiveFlag; 
int MouseDounFlag; 
COffscreenBuffer *pOffscreenBuffer; 



the loop sees a message it cares about, it 
calls out to some other set of functions to 
process the event, then returns its ear to 
the queue and continues until the user 
exits the application. Pretty basic stuff. 



A II we have to do is plug in to the appro- 
priate queue. 

On both systems, windows provide 
the atomic units of graphical applications, 
so most messages are tied to individual 



windows as the user performs actions on 
them. T he application just creates a win- 
dow, calls on the system to process events, 
handles game logic, and renders until the 
program terminates. Our goal today is to 
encapsulate all this in a platform- inde- 
pendent game loop that looks like this: 

void XSplatHain(void) 
{ 

// Create a 320x240 uindou with the 
title "XSplat Windou" 
CXSplatWindou *pWindou = new 
CXSplatWindou ( " XSplatWindou " , 320 , 
240); 

if (pWindou) 
{ 

uhile (GamelsRunning) 
{ 

DispatchEventsO; 

DoGameLogicO; 

RenderO; 

} 

// Get rid of the uindou for good 
delete pWindou; 

} 

} 

All the logic of the user interface 
takes place in the CXSplatWindou object. 
DispatchEvents translates messages from 
the system into CXSplatWindou methods, 
DoGameLogic controls the actual flow of the 
non-event- based portions of the game, if 
any, and Render displays the current game 
state on the screen. Figure 1 shows this 
platform- independent architecture. 

Event notification differs signifi- 
cantly between the M acintosh and W in- 
dows systems. The M acintosh pours all 
its messages through one pipe, requiring 
that the application filter and distribute 
messages at the receiving end of the pipe. 
I n W indows, the message filter sits at the 
sending end of the pipe, and the system 
eases the burden by passing messages out 
to individual windows instead of to the 
controlling application. 

Big deal. CXSplatWindou provides an 
adapter that plugs onto either end and 
redirects messages however we want 
them. T his funnel adapter can even han- 
dle many system messages itself, passing 



#if defined(.WINDOWS) 

// Windous implementation details 

HPALETTE Palette; 
HWND Windou; 

friend LONG PASCAL XSplatWindouProc(HWND, UINT, WPARAH, LPARAH); 

#elif defined(JACINTOSH) 

// Macintosh implementation details 

WindouPtr Windou; 
PaletteHandle WinPalette; 

friend void HandleMouseDoun(EventRecord *pEvent); 
#endif 

// This is the XSplat message processing system 
void DispatchEvents(void); 



// This is the XSplat main function, called from WinMain or 
// from main after platform-specific setup 
void XSplatMain(void) ; 



32 GAME DEVELOPER - OCTOBER/NOVEMBER 1995 



Listing 2. CXSplatWindow Constructor for Win32 



// This will be used as the window class name for CXSplatUindows 
static char XSplatWindowQassName[] = "XSPLAT"; 

// This will be the window style of all new created CXSplatUindows 
// For now, don't allow the window to be resized 
static const DWORD XSplatUindowStyle = 
US_OVERLAPPEDUINDOU k ~US_THICKFRANE; 

CXSplatWindow: :CXSplatUindow(const char *Caption, int UindowUidth, 
int UindowHeight, unsigned char const *Colors) : 
Palette(O), Uindow(O), pOffscreenBuffer(O) , 
IsActiveFlag(O) , MouseDownFlag(O) 



{ 



extern HINSTANCE ghlnstance; 
assert (ghlnstance); 

// Register the XSplatUindow class if it isn't already registered 
int Success = 1; 
UNDCLASS Qasslnfo; 

if (IGetClassInfo (ghlnstance, XSplatUindowClassName, JiClassInfo)) 
{ 

= LoadCursor(0, IDCJRROU); 



ClassInfo.hCursor 
Classlnf o . hlcon 
Classlnf o .IpszMenuName 
Classlnf o.lpszQassName 
Classlnf o . hbrBackground 
Classlnf o.hln stance 
Classlnf o . style 
Classlnf o .lpf nUndProc 
Classlnf o . cbUndExtra 
Classlnf o . cbClsExtra 



Loadlcontghlnstance, IDIJPPLICATION); 
0; 

XSplatUindowClassName; 
HBRUSH(GetStockObject(UHITE_BRUSH)) ; 
ghlnstance; 

CS.VREDRAU I CS.HREDRAU I CSJUNDC; 
UNDPROC(XSplatUindowProc); 
0; 
0; 



} 



Success = RegisterQass(!tQassInf o) ; 



if (Success) 
{ 

// Determine screen dimensions 

int ScreenUidth = GetSystemMetrics(SM_CXSCREEN) ; 

int ScreenHeight = GetSystemnetrics(SH_CVSCREEN); 

// Given a zero or negative dimension, fill the screen 
if (UindowUidth <= 0) 

UindowUidth = ScreenUidth; 
if (UindowHeight <= 0) 

UindowHeight = ScreenHeight; 

// Determine the window size for the requested client area 
RECT UindowRect = { 0, 0, UindowUidth, UindowHeight }; 
AdjustUindowRect(iUindowRect, XSplatUindowStyle, 0); 

// Hake sure it's not larger than the screen 

int UindowUidth = UindowRect. right - UindowRect.left; 

if (UindowUidth > ScreenUidth) UindowUidth = ScreenUidth; 

int UindowHeight = UindowRect. bottom - UindowRect. top; 

if (UindowHeight > ScreenHeight) UindowHeight = ScreenHeight; 

// Create the window centered on the screen 
int Left = (ScreenUidth - UindowUidth) / 2; 
int Top = (ScreenHeight - UindowHeight) / 2; 

Uindow = CreateUindow(XSplatUindowQassName, Caption, 

XSplatUindowStyle, Left, Top, UindowUidth, UindowHeight, 
0, 0, ghlnstance, 0); 

if (Uindow) 
{ 

// Store a pointer back to this object in GUL_USERDATA 



SetUindowLong(Uindow, GUL.USERDATA, (long)this); 

// TDD0: Set up the palette from the given Colors 
// T0D0: Ue'll do this in a later article... 
// For now, create a gray wash 
struct 
{ 

U0RD Version; 

U0RD NumberOf Entries; 

PALETTEENTRV aEntries[256] ; 
} LogPalette = 
{ 

0x300, // Palette version 
256 // Number of colors 

}; 

for (int i=0; i<256; ++i) 
{ 

LogPalette. aEntries[i] .peRed = 

LogPalette. aEntries[i] .peGreen = 
LogPalette. aEntries[i] .peBlue = i; 

LogPalette. aEntriesfi] .peFlags = 0; 
} 

Palette = CreatePalette( (LOGPALETTE *)M_ogPalette); 

// Initialize the Window's DC as necessary 

// Since it's a CS_0UNDC, these settings will last 

// forever 

HDC hdc = GetDC(Uindow); 
if (hdc) 
{ 

SetMapMode(hdc, HH_TEXT); 
SelectPalette(hdc, Palette, FALSE); 
RealizePalette(hdc); 

// This isn't really necessary, but... 
ReleaseDC(Uindow, hdc); 



// All ready to go, show the window 
ShowUindow(Uindow, SU.NORHAL); 

// Set up the offscreen environment. Note that because 
// of the way COffscreenBuffer was originally defined, 
// the window must be visible and active 
assert(GetActiveUindow() = Uindow); 
pOffscreenBuffer = new COffscreenBuffer; 




along only a 
handful of 
important 
events such as 
keyboard and 
mouse input. 

L isting 1 
shows a decla- 
ration of a min- 
imal CXSplatWin- 
dou interface, 
whose member 



functions you may want to virtualize. I've 
combined M acintosh and 32-bit W in- 
dows declarations using the preprocessor 
symbols .windows and .macintosh, defined 
elsewhere. There's also a friend called 
XSplatWindouProc required by the W in32 
CXSplatWindow implementation, for reasons 
I'll describe shortly. 

Constructing Windows 

A CXSplatWindow is more than just a mes- 
sage filter. It's the atomic unit of the 



GAM E DEVELOPER • OCTOBER/NOVEM BER 1995 33 



IS P L H T 



XSplat interface, the atomic unit of 
either target system. It's a visible, 
interactive piece of the user interface. 

The CXSplatWindow constructor 
creates a window using platform- 
specific system functions. We pass 
along a title, an optional height and 
width, and an optional array of 768 
bytes describing 256 RGB triplets 
(XSplat assumes an 8-bit palletized 
display, and we'll deal with palettes 
in a future article). If height or width 
is omitted, zero, or negative, the 
constructor creates a window that 
fills the screen in the omitted dimen- 
sion. N o value or a null pointer for 
CoiorArray tells the constructor to use 
a default gray wash for the window. 

So the command: 

CXSplatWindow *pWindow = new 
CXSplatWindow ("Testing"); 

will create a full-screen window 
with a gray wash and the title 'Test- 
ing." 

W e'll want the window to 
display an image of our own cre- 
ation, SO we'll create a COff screen- 
Buffer for every CXSplatWindow 
using the code introduced in my 
last article (to access this code, go 
to the Game D eveloper ftp site at 
ftp://ftp.mfi.com/gdmag/src). 

T he CXSplatWindow constructors 
are very simple and hide the nuances 
of each platform from XSplat appli- 
cations. Listing 2 shows the 32- bit 
W indows version, and L isting 3 
shows the M acintosh version. Let's 
take a look at what's going on in 
each. 

I n W indows, every window 
requires an associated window class, 
and every window class requires an 
associated window procedure. Before 
creating a window, the constructor 
makes sure the window class xsplat 
has been registered for a window 
based on the XSplatWindowProc proce- 
dure. This requires an instance han- 
dle, provided through a global ghin- 
stance handle that we set up in Win- 
Main. We'll take a look at XSplatWin- 
dowProc, a target for the W indows 



Listing 3. CXSplat Window Constructor for Macintosh 



CXSplatWindow: : CXSplatWindow (const char *Caption, 
int WindowWidth, 

int WindowHeight, unsigned char const *Colors) 
WinPalette(O), Uindow(O), pOffscreenBuffer(O), 
IsActiveFlag(O) , MouseDownFlag(O) 



{ 



// Determine the screen size 

int ScreenWidth = qd.screenBits. bounds. right - 

qd . screenBits . bounds .left ; 
int ScreenHeight = qd.screenBits. bounds. bottom • 

qd . screenBits . bounds . top ; 



// Given a zero or negative dimension, fill the 
// screen 

if (WindowWidth <= 0) 

WindowWidth = ScreenWidth; 
if (WindowHeight <= 0) 

WindowHeight = ScreenHeight; 

// Create the window centered on the screen 
int Left = (ScreenWidth - WindowWidth) / 2; 
int Top = (ScreenHeight - WindowHeight) / 2; 

Rect WindowRect = {Top, Left, 

Top + WindowHeight, Left + WindowWidth}; 

// Convert the caption to a pascal string 
// TODD: This doesn't do well with non-ASCII 
// character sets. . . 
char unsigned PascalCaption [256] ; 
strcpy((char *)&PascalCaption[l] , Caption); 
PascalCaption [0] = (char unsigned)strlen(Cap- 
tion); 



// Create a new color document window with these 
// dimensions 

Window = NewCWindow(0, SiWindowRect, PascalCap 
tion, TRUE, noGrowDocProc, WindowPtr(-l), 
TRUE, 0); 

if (Window) 

{ 

// Store a pointer back to the window 
SetWRef Con (Window , (long)this) ; 

// TODD: Set up the palette from the given 
// Colors 

// TODO: We'll do this in a later article... 
// For now, create a gray wash 
// Create a palette for the window and make 
// sure it will give a 1:1 color mapping 
// with pmExplicit I pmAnimated. 
WinPalette = NewPalette(256, 0, pmExplicit I 
pmAnijnated, 0); 

if (WinPalette) 
{ 

for (int i=0; i<256; ++i) 
{ 

RGBColor rgb; 
rgb.red = i « 8; 
rgb. green = rgb.red; 
rgb. blue = rgb.red; 



} 



SetEntryColor(WinPalette, i, fcrgb); 



SetEntryUsage(WinPalette, 0, pmExplicit 
I pmAnimated, 0); 

SetEntryUsage(WinPalette, 255, pmExplic- 
it I pmAnijnated, 0); 

SetPalette(Window, WinPalette, FALSE); 



} 

// Initialize the Window 
SetPort(Window); 
ForeColor(blackColor) ; 
BackColor(whiteColor) ; 
PenNormalO; 

// Set up the offscreen 
// environment. Note that because 
// of the way COffscreenBuffer was 
// originally defined, the 
// must be visible and active 
pOffscreenBuffer = new COffscreen- 



Buffer; 
} 

} 



window 
ve 

screen- 



messaging mechanism, a little later. 

The xsplat window class uses the 
CS_0WN.DC style; changes to the window's 
device context will remain across 
GetDC/ReleaseDC calls. On W indows 3.1 
(and on Win32s), CS.OWNDC windows eat 
up precious system resources, but it's well 
worth it for this type of application. n 
W indows NT and W indows 95, there's 
not really anything to worry about. 

nee it has a window to work with, 
the W indows constructor creates a gray 
wash palette using a fake LOGPALETTE 
structure on the stack, initializes the win- 
dow's device context, and creates an asso- 
ciated COffscreenBuffer. W hen the win- 
dow is ready, it's revealed to the user. 

The M acintosh CXSplatWindow con- 
structor does almost exactly the same 
thing. It creates a window with the given 
dimensions using the system call NewCWin- 
dow, creates a gray wash palette associated 
with the window, initializes the drawing 
system for the window, and attaches a 
COffscreenBuffer object. 

The CXSplatWindow object holds a 
system- specific reference to the associat- 
ed system- specific window (hwnd on 
W indows and WindowPtr on M acintosh). 
H owever, the message dispatching func- 
tions need to associate a CXSplatWindow 
object with a system-specific window. To 
do this, we'll take advantage of functions 
on both platforms that attach 32 bits of 
application-specific data to any window. 
n W indows, the A PI to do this is 
SetWindowLong. Its M acintosh twin is 
SetWRefCon. XSplat uses these 32 bits to 
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store a pointer back to a cxspiatwindow 
object, used by DispatchEvents to reroute 
system- specific messages to more general 
CXSplatWindou controllers. 

Two other member variables, isAc- 
tiveFlag and MouseDounFlag need some 
examination. These variables (I've made 
them individual integers for simplicity) 
will store information received as a result 
of MouseDoun/Mousellp and Activate/Deacti- 
vate events. T here's a lot more to cover 
before we can address those functions, 
though. Specifically, we need a message 
switchboard to translate system events 
into calls to CXSplatWindou objects. 

Passing Messages 

The XSplat function DispatchEvents han- 
dles the polling and processing of system 
messages. To build a single-window 
application, just create a CXSplatWindou 
object, and DispatchEvents will do the rest. 

On Windows, DispatchEvents per- 
forms a standard PeekMessage/Trans- 
lateMessage/DispatchHessage dance. The 
real event filtering occurs in the 
xSpiatWindouProc procedure, the recipient 
of all messages dispatched to XSPLAT win- 
dows this way. W hen a message of inter- 
est enters XSpiatWindouProc, the procedure 
passes it on to the CXSplatWindou object 
associated with the target window. 
U nless some evil application has mucked 
with the window's instance data, we can 
be sure of finding a valid pointer to the 
CXSplatWindou object using GetWindouLong. 

On the M acintosh, DispatchEvents 
calls WaitNextEvent to look for events. As 
long as it finds events in the queue, it 
either handles these according to some 
default behavior or passes them on to the 
appropriate CXSplatWindou, retrieved 
through a GetWRefCon call. This is exactly 
the same process as DispatchEvents under 

W indOWS, Without the XSpiatWindouProc 
step in the middle. 

The M acintosh XSplat switchboard 
has to be smarter than its W indows 
counterpart because the operating system 
doesn't always associate events with win- 
dows. In particular, there's no real sup- 
port for the promised mouse movement 
events. WaitNextEvent can tell you when 
the mouse leaves a given region, but we 
want to know whenever and wherever the 



Listing 4. Some of the Win Dispatch Architecture (Con't. on p. 36) 



// Windows DispatchEvents is very minimal. It just forces the 
// system to pass events on to XSpiatWindouProc 
void DispatchEvents(void) 
{ 

MSG Message; 

while (PeekMessageWMessage, 0, 0, 0, PM.REMOVE)) 
{ 

TranslateMessage(SiMessage) ; 
DispatchMessage(iiBessage) ; 

} 

} 

LONG PASCAL XSplatWindouProc(HWND Windou, UINT Message, WPARAM wParam, 
LPARAM lParam) 

{ 

// You don't really need the pXSplatWindou to process all 
// messages — most just go through DefWindouProc anyway. If you're 
// concerned, move this into the messages that really care. 
CXSplatWindou *pXSplatWindou = 

(CXSplatWindou *)GetWindowLong(Window, GWL_USERDATA) ; 

suitch(Message) 
{ 

case WM_ ACTIVATE: 

// Re-realize the palette on activate 
if (pXSplatWindou) 
{ 

HDC hdc = GetDC(Windou); 

SelectPalette(hdc, pXSplatWindov->Palette, FALSE); 
ReleaseDC(Window, hdc); 

// Let the CXSplatWindou knou that it's becoming active 
if (LOWORD(wParam) != UA.INACTIVE) 
pXSplatWindou->Activate() ; 

else 

pXSplatWindou->Deactivate() ; 

} 

break; 
case WM.CHAR: 

pXSplatWindou->KeyDown((char)wParam, LOWORD(lParam)); 
break; 

case WM.CLOSE: 
case WM.DESTROY: 

if (pXSplatWindou) 
{ 

// Avoid a bad delete/WM.DESTROY loop 
// Reset the pointer back here to avoid confusion 
pXSplatWindou->Uindow = 0; 

} 

GameRunningFlag = 0; 
break; 

case WM.LBUTTONDOWN: 
SetCapture(Windou); 
if (pXSplatWindou) 

pXSplatWindou->MouseDown(L0W0RD(lParam), HIWORD(lParam)); 
break; 

case WM_LBUTTONUP: 
ReleaseCaptureO; 
if (pXSplatWindou) 

pXSplatWindou->MouseUp(LOWORD(lParam) , HIWORD(lParam) ) ; 
break; 

case WH.H0USEH0VE: 
if (pXSplatWindou) 

pXSplatWindou->MouseMove(L0W0R0(lParam) , HIWORO(lParam) ) ; 
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Listing 4. Some of the Win Dispatch Architecture (Con't. from p. 35) 




mouse changes position anywhere on the 
screen, relative to the origin of the win- 
dow's content region. So every time it 
goes through the loop, DispatchEvents 
checks the current mouse position and 
passes it through to the appropriate CXS- 
platWindou if it has changed. 

But how do we decide on an 
"appropriate window?" In W indows, we 
can capture the mouse using SetCapture 
after a mouse down event so that all 



subsequent mouse events go to that win- 
dow, then release the capture when the 
button comes up. Because the M acin- 
tosh version generates its own mouse 
events, it also must keep its own capture 
information. 

W hen a mouse down event occurs 
in the content region of a window, Han- 
dieMouseDown stores a pointer to the CXS- 
platWindou receiving the event. Dis- 
patchEvents passes subsequent mouse 



events to that cxspiatwindou, resetting the 
capture pointer on the next mouse up 
event. If there's no window receiving the 
capture, DispatchEvents will pass the 
events on to the cxspiatwindou associated 
with the front window. 

On both platforms, DispatchEvents 
provides default behaviors for application 
activation and deactivation, window 
dragging and resizing, and basic system 
events. It also handles window updates 
by copying the COffscreenBuffer to the 
screen through standard methods. All the 
application has to deal with are the 
aspects that make it unique: responding 
to the mouse, pausing the game on deac- 
tivation, and constructing the off-screen 
image. 

Unfortunately, there's not enough 
space here to print or describe the two 
systems in their entirety. T o give you the 
general feel for what's going on, L istings 
3 and 4 show important pieces of the 
X Splat event management functions for 
both platforms. Events coming through 
system-specific channels such as wm.lbut- 
TONDOWN or mouseDoun notifications are 
turned into calls to cxspiatwindou objects, 
which don't have to worry about the 
source of the message. Again, complete 
source code is available on ftp.mfi.com. 

A Complete Application 

Let's create a complete application using 
the X Splat system so far, just to prove 
that it can actually be done. Since all the 
messaging, window creation, and double 
buffering has been set up, we only have 
to implement XSplatMain, W indOWS Win- 
Main, and Macintosh main, then we need to 
implement a cxspiatwindou object. 

W e need a simple application that's 
going to use the architecture so far. H ow 
about a rudimentary paint program? T his 
application will present a small (320-by- 
240) window filled with the colors of the 
palette (a gray wash, for now). As you 
click the mouse button and drag the cur- 
sor across the window, the application 
will invert the pixels it touches, and you'll 
be able to draw simple pictures. 

First, we'll need an XSplatMain that 
sets up a cxspiatwindou and fills it with a 
cycle of palette colors before entering a 
standard message processing loop. 
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Listing 5. A Very Simple Drawing Application Using XSplat 



// GameRunningFlag is reset by the event handling system when 
// the user quits the game, 
int GameRunningFlag = i; 

void XSplatMain(void) 
{ 

// Create a 320x240 window with no specific colors 
CXSplatWindow *pWindow = 

new CXSplatUindowC XSplat Test Application", 320, 240); 

if (pUindow) 
{ 

// Fill the buffer with the palette in horizontal lines 
COffscreenBuffer *pBuffer = pWindow->GetOf f screenBuf f er() ; 
if (pBuffer) 
{ 

pBuffer->Lock(); 

char unsigned *pBits = pBuffer->GetBits() ; 
for (int y=0; y<pBuffer->GetHeight() ; ++y) 
{ 

memset((»oid *)pBits, y '/, 256, pBuffer->GetUidth()); 
pBits += pBuffer->GetStride(); 

} 

pBuffer->Unlock(); 

} 

// Loop until termination 
while (GameRunningFlag) 
{ 

DispatchEventsQ; 

} 

delete pUindow; 



// Here's where the work is done: any time the mouse moves 

// within the buffered area while the window is active, invert a 

// pixel and redraw the window. 

// Of course, swapping in the whole buffer in response to one 
// pixel change is ridiculous, but hey, this is only a test. 



void CXSplatWindow : Activate (void) 



IsActiveFlag = 1; 



void CXSplatWindow: :Deactivate(void) 
{ 

IsActiveFlag = 0; 
} 

void CXSplatUindow : :MouseDown(int x, iny) 
{ 

HouseDownFlag = 1; 



void CXSplatUindow : :MouseUp(int x, int y) 
{ 

MouseDownFlag = 0; 
} 

void CXSplatWindow : :MouseHove(int x, int y) 



{ 



if (IsActiveFlag U MouseDownFlag Ut 
x >= a y >= lit 
x < pOffscreenBuffer->GetUidth() M 
y < pOffscreenBuffer->GetHeight()) 

{ 




pOff screenBuf fer->Lock() ; 

char unsigned *pPixel = pOff- 
screenBuffer->GetBits() + 

pOff screenBuf fer->GetStride ( ) 

* y + x; 

♦pPixel = "(*pPixel); 

pOff screenBuf fer->SwapBuffer() ; 
pOff screenBuf fer->Unlock() ; 



Second, we'll need a cxspiatwin- 
dou: :MouseMove that flips pixels in response 
to mouse movement whenever the mouse 
button is down and the window is active. 
The other CXSplatWindou functions set 
mousedown and window activation flags. 
To keep things easy to implement, we'll 
swap in the whole buffer whenever a pixel 
changes. In a real situation, this would be 
ridiculous, but for now all we have is 
COffscreen: :SuapBuffer, which is good 
enough for this little test. 

L isting 5 shows the implementation 
of the platform-independent application. 

See You Real Soon 

So far, we have a completely functional 
(though very simple) drawing application 
that runs on several platforms. T he code 
to implement the specific behavior of the 
application used XSplat interfaces to 
avoid platform dependencies, and as the 
XSplat messaging, windowing, and dou- 
ble-buffering system grows beneath us, 
we'll be able to write more complex 
games that should only rarely have to 
know what kind of computer they're run- 
ning on. 

I n the next article in this series, we'll 
address palettes and the color zero prob- 
lem, take a look at some of the flaws in 
the design so far, and move on with the 
design and implementation of a real 
XSplat demo game. Seeyou then! ■ 

After revealing his employer at the end 
of his last artide, Jon Blossom left himself 
wide open to an onslaught of vidous head- 
hunters and had to fight them off with a 
bamboo cane. You can reach him via e-mail 
at blossom@mobius.net or through Game 
Developer magazine. 
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Hpril 1, 1995, is a day I II remem- 
ber as long as I live. I was up in 
the gold country of California 
for a nice drive. 1 1 wasn't the Sil- 
icon Valley, so it suited me all 
the better. I pulled into an out- 
of-the-way filling station to top 
off my tank— enough to make it 
back to the freeway. It was getting dark, 
and the last thing I wanted to do was to 
run out of gas on a lonely back road. 

The station attendant, old and sim- 
ple, spoke only in binary, answering each 
question with "Yep" and "N ope." I handed 
him my 15 bucks for the lousy seven gal- 
lons of gas. That's when it all happened. 
An old topless Chevy Blazer skidded onto 
the crumbling asphalt, almost rear-ending 
my car. T hree young men leaped out of the 
truck. Their faces were stone white like 
they had seen a ghost. ne of them 
yanked the passenger side door open, 
almost pulling the muddy door off its 
hinges. A young woman lifelessly fell out 
of theseat. Shewas alive but limp, her eyes 
were open and focused on nothing. 

I raced over to lend a hand. "W hat 
happened here gentlemen?" I asked as I 
cushioned her head with my rolled up 
jacket. 

"We've seen it...," the driver spoke 
frantically. 

"Seen what?" I asked. T here was no 
answer. The young men stared at each 
other, looking for a reason to break some 
unknown secret. 

Something was strange about these 
fellows. I walked around their vehicle, 
but saw nothing out of the ordinary. 
There were four yellow helmets in the 
back with California Dept. of Forestry 
insignias on them. T he back of the truck 



held chain saws and shovels. A fresh 
dent was in the side of the truck. I 
looked through the driver's open door 
and saw a laptop plugged into the AC 
outlet of a cigerette lighter. I looked up 
at one of the young men. H is fearful eyes 
met mine, and he looked back at the lap- 
top. I could tell by the frightened look 
on his face that this was the key to what- 
ever happened in the woods. 

H e watched me as I pulled the com- 
pass off the dashboard of the Blazer and 
held it over the computer. It spun wildly 
with no sense of direction to the magnetic 
N orth Pole. Amazing, I thought to myself. 
This can't be happening, but it is. These 
were young people, who but just an hour 
ago, believed their young selves to be 
immortal. But something changed us all 
that night. Something I never believed to 
be true. I was bearing witness to people 
who had actually had a modeX encounter 
of the first kind. 

When I got back that night to my 
house. I immediately searched the internet 
for information regarding modeX. There 
was hardly any solid information— nothing 
to attribute to what I saw the previous 
night. There were documents of others 
who had witnessed mode X and a listing of 
talk shows like M ontel Williams and Don- 
ahue with upcoming episodes featuring 
modeX encounters. 

But what interested me the most 
were the references to a certain man— 
M ichael A brash— supposedly hired to 
reverse engineer this alien technology. 
A brash had published several articles about 
it in credible journals. These allegedly con- 
tained detailed accounts of programming 
mode X. I n some cases, there were refer- 
ences to using mode X to go beyond two 
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dimensions at an unearthly speed. 

After more exhausting searches, again 
all pointing to M ichael A brash, I decided 
to rip apart his code and get answers for 
myself. M y quest was clear: define the fun- 
damentals of mode X to use in my graph- 
ics library. So I set forth on my metaphysi- 
cal pilgrimage, a man, his computer, a 
bible on graphics, a notebook, a pencil, a 
scientific calculator, and some C heetos. 

The following is the result of myout- 
of- assembly- language experience— every- 
thing I witnessed, touched, sensed, and 
discovered in the couple of weeks that I 
locked myself in my study, unshaven but 
not fasting. I wish to clarify that I was a 
digital religious zealot and not a fanatic. 
W hen I finally cracked open my door and 
emerged with the answers, my nostrils 
flared as fresh air from the hall rushed into 
the cluttered room. W hat I discovered 
during this time alone is carefully docu- 
mented. Some of you out there may not 
believe what I have seen. But I don't care. 
I t's true. A nd it really happened to me. 

W ithout further ado, I present an 
accurate account of information, unedited, 
as it happened, of the strange goings on 
and alien technology used in setting mode 
X. Oddly, this information is in no way 
documented by physicist Bob Lazarand in 
no way relates to accounts of extraterrestri- 
al technology hidden in the N evada desert 
or the alleged Sport model U F . T he log- 
ical place to start is with a prophetic ques- 
tion, "W hat is mode X , where did it come 
from, and what is it doing here?" 

M ode X is an undocumented and 
unsupported video mode that uses VGA 
hardware efficiently in 256 colors. The Air 
Force, the mysterious men in black, and 
IBM deny its existence. G ame developers 



stumbled on this mysterious graphics 
mode early on, and the most elaborate and 
credible witness is M ichael A brash author 
of these now infamous accounts. 

W itnesses describe mode X as having 
a resolution of 320-by-240 pixels, using 
four 64K planes of VGA memory, and 
supporting page flipping. Further, a page 
of memory in mode X is only 76,800 pixels 
long. D ocuments released under the F ree- 
dom of I nformation A ct describe industrial 
implementations using a page- flipping 
scheme in mode X with speeds unprece- 
dented by the I BM -supported mode 13h. 
This document goes on to indicate that 
mode X still has adequate video memory 
to store a static backdrop and sprites. 

Information released, based on 
M ichael A brash's prophetic testimony, is 
described herein. Places where IBM trun- 
cated A brash's original text with heavy 
black markers is carefully pieced together 
for continuity and validity. 

Untangling VGA Mode X 

After placing a few phone calls, I located a 
credible eyewitness. I convinced the 
woman, who requested not to be identi- 
fied, to meet me in a restaurant and discuss 
what she knew about configuring this 
mysterious mode. I convinced her that I 
wasn't with IBM, and as long as she 
divulged what she knew to me, I would get 
it to the public. 

Fearing for her own safety, she insist- 
ed that she tell me only one of two secrets 
she knew firsthand— the location of the 
alien corpses from the 1947 Roswell inci- 
dent or solid information on setting mode 
X . I wanted mode X . H er face went white 
and, with a shaking hand, she reached into 
her purse and pulled out a gold C ross pen. 



Michael J . Norton 



Fox's new advertising 
theme: Programming 
for Node X is cool. 
Cool line us. 
Here is on account of 
a close encounter 
with this alien 
technology. 
[The truth is 
out there]. 
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She glanced over her shoulder, then 
sketched out the following information on 
a napkin. She finished in under five min- 
utes and downed her Fresca. Before her 
hasty flight she told me never to contact 
her again. 

T he notes from the napkin are trans- 
lated here. It was a very big napkin. 

Programming in mode X is tedious 
and not as straightforward as mode 13h. 
For instance, VGA can be set to model3h 
by calling the bios function. The function 
in L isting 1, written in W atcom C 44, sets 
a video mode by passing it the mode value. 
For example: 

setVideoMode( 0x13 ); 

// sets video to mode 13h 



Listing 1. Using Bios to Set 



void setVideoModet int xmode) 
{ 

union REGS regs; 

regs. u. ax = xmode; 

int386( 0x10, Siregs, fcregs); 

} 



Because mode X is unsupported by 
bios, you are left with the task of chang- 
ing the video mode. You can achieve this 
by setting mode 13h with a call to bios 
and tweaking the video registers to the 
desired mode. The first objective is to 
remove the chain 4 attribute from video 
mode 13h. T his is what makes mode 13h 
appear to be a single linear plane. The 
chain 4 mode can be turned off by alter- 
ing bits in the VGA's sequencer registers. 
The reset register, index 1, and the mem- 
ory mode register at index 4 need to be 
set as follows: 

#define SEQC.INDEX 0x03c4 

// sequence controller index 
outpu( SEQC.INDEX, 0x0604 ); 

// disable chain 4 mode 

A brash recommends setting the clock 
to 25M H z for fixed-frequency monitors. 
This involves invoking a synchronous reset 
to stop the sequencer, setting the clock to 
the new scan rate, and restarting the 
sequencer: 



#define MISC.OUTPUT 0x032c 

// miscellaneous output register 
outpu( SEQC.INDEX, 0x0100 ); 

// reset, stop the sequencer 
outpu( MISC.OUTPUT, 0x0e3 ); 

// select 25MHz dot clock and 
60Hz scanning rate. 
outpu( SEQC.INDEX, 0x0300 ); 

// restart the sequencer 

The last obstacle to tackle in setting 
mode X is to write the proper values into 
the CRT controller (CRTC) registers. 
W riting to the C RTC registers requires 
having write privileges. On VGA, bits 6 
and 7 of the CRTC register, vertical 
retrace end, are used to protect CRTC 
registers at indexes through 7: 

#define CRTC.INDEX 0x03d4 
#define VRE.REGISTER 0x11 
outp( CRTC.INDEX, VRE.REGISTER); 

// CRTC write protect bit 
outp(CRTC.INDEX + 1, (inp(CRTC.INDEX + 
1) ft 0x7f)); 

// remove write protect 

T he write protect on various registers 
of the CRTC has now been lifted, so new 
values for mode X can be set. The values 
being passed are the parameters A brash 
provided in his code, shown in Listing 2. 

Finally, to wrap up setting modeX, 
the map mask register, index 02h, of the 



sequencer registers needs to be informed of 
how the memory planes are to be orga- 
nized. I n the case of mode X , all four 
planes need to be enabled: 

outpu( SEQC.INDEX, 0x0f02 ); 

// enable writes on all four planes. 

Why didn't IBM include mode X as 
a supported video mode? Other video 
modes are plane oriented, likeVG A mode 
02h. In fact, mode 13h is plane oriented, 
but its planes are chained to make it appear 
as a linear address space. T his feature is a 
good one because of the simplicity it offers 
in programming. However, chained 
planes, in this case four planes per pixel, 
throw off the pixel spacing. T he resolution 
is nonsquare, where mode X provides 
square pixel spacing, with one plane per 
pixel. The aspect ratio of mode X is 1:1. 
W hy IBM didn't offer a complimentary 
plane- oriented mode to 13hlikemodeX is 
certainly a mystery. 

Figures 1A and IB show chained- 
plane mode 13h and mode X referencing 
pixels Listing 3 showshowsto set modeX 
with the W atcom 10.0 compiler. 

Navigating Mode X 

Of course, no information or key witness is 
valid without the testimony of an expert. I 
took the original notes and the napkin to a 
close friend at Stanford U niversity who is 



Listing 2. Abrash's Parameter Values 



(define 
(define 
(define 
(define 
(define 
(define 
(define 
(define 
(define 
(define 



VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 



.vertical.total 

overflow 

hax.scan.line 

vert.retrace.start 

vert.retrace.low 

vert.display.end 

underline.location 

vert.blank.start 

vert.blank.end 

bode.control 



0x00d06 
0x03e07 
0x04109 
OxOealO 
OxOacll 
0x0dfl2 
0x00014 
0x0e715 
0x00616 
0x0e317 



output 
output 
output 
output 
output 
output 
output 
output 
output 
output 



CRTC.INDEX, 
CRTC.INDEX, 
CRTC.INDEX, 
CRTC.INDEX, 
CRTC.INDEX, 
CRTC.INDEX, 
CRTC.INDEX, 
CRTC.INDEX, 
CRTC.INDEX, 
CRTC.INDEX, 



VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 



VERTICAL.TOTAL ); 
OVERFLOW ); 
HAX.SCAN.LINE ); 
VERT.RETRACE.START ); 
VERT.RETRACE.LOW ); 
VERT.DISPLAY.END ); 
UNDERLINE.LOCATION ); 
VERT.BLANK.START ); 
VERT.BLANK.END ); 
HODE.CONTROL ); 



// vertical total 
// overflou 

// set for double scan 

// vsync start 

// v sync end and protect 

// vert displayed 

// turn off dword mode 

// v vblank start 

// v blank end 

// turn on byte mode 



42 GAME DEVELOPER - OCTOBER/NOVEMBER 1995 



Figure la. VGA Mode 13h 64K Linear Bitmap Organization I Figure lb. VGA Mode X Plane Memory Organization 
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part of the SE T I project. H e took one look 
at the notes and sat down in awe. H e told 
me that while I was waiting I could take a 
peak at some data of what he believed to 
be signals from an extra-terrestrial civiliza- 
tion. 

I told him I was not in the least bit 
interested and to concentrate on the infor- 
mation I had provided him. By 2:00 the 
following morning— and three large 
combo pizzas later— we staggered over to 
an XW indows terminal logged into a C ray 
supercomputer. Characters of alien origin 
shot across the screen. W hat does this all 
mean I asked myself. M y affiliate reached 
into his drawer and pulled out a wire 
hanger wrapped in aluminum foil. H e 
informed me to stick my head out the win- 
dow and hold the hanger still on his mark. 

"N ow," he yelled as he scrambled to 
dump the file to a print queue. 

By now, its obvious that working in 
the mysterious mode X is not as simple as 
its supported, chained planar video mode 
13h is. Plotting pixels in a linear bitmap is 
easy. But now that the attributes of the 
video memory have been modified and its 
chained mode disabled, navigating this 
alien mode can be difficult. 

M ode X and mode 13h do share two 
commonalities: that they're both one byte 
per pixel and they both have 320 columns 
per row. T he latter is true because mode X 
is a hybrid video mode of 13h and only the 
scan lines were reconfigured. 

To write a pixel, a pointer must be 
initialized to reference video memory. This 



240 



example uses 
DOS4/GW and 
C ++, so the video 
pointer will not be 
type far. I n protect- 
ed mode under 
DOS4/GW, the 
video memory is 
mapped in the same 
segment as the 
code. To set a 
pointer to VGA 
memory, be it mode 
13h or mode X, we 
use the following 
snippet of code: 



char *pVideoMem; 

// pointer to VGA memory, D0S4/GW 
pVideoMem = (char*)(0xA0000); 

// initialize pointer to VGA memory. 

DOS4/GW uses physical memory 
addresses; that's why the pointer was ini- 
tialized to location OxAOOOO and not seg- 
ment A000:000. T his pointer references the 
first byte in VGA memory at offset 0. In 
plain E nglish, this is the first pixel in the 
upper left-hand corner of the screen. The 
pixel can be plotted by assigning the loca- 
tion a byte value: 

char pixelValue; 

// a value to urite to memory 
pixelValue = 127; 

// assign a value 
*pVideol"lem = pixelValue; 



t V 

Pixel Pixel 4 Pixel 8 



> • Pixel n-3 Plane 



Pixel 1 Pixel 5 Pixel 9 



Pixel n-2 Plane 1 



1 



Pixel 2 Pixel 6 Pixel 10 

1/ 



Pixel 3 Pixel 7 Pixel 11 



• • • Pixel n-1 Plane 2 



' • Pixel n Plane 3 



4 x 64k Planes of Display Memory 

// urite the value to memory 

T his code is useful if we only write to 
the first coordinate of the screen, but what 
about the tens of thousands of other pixels 
we wish to set? To plot other pixels, we 
will need to understand how video memo- 
ry is organized. 

In mode 13h, video memory is 
chained to give it a flat bitmap effect. The 
plotting of a pixel in one of the 320 
columns by 200 rows is a simple matter of 
arithmetic. For instance, to plot a point, 
P(109,47), where X =109 and Y=47, we 
simply calculate the scan line and the byte 
offset into the scan line of the location we 
wish to plot. 

To compute the scanline (or row) 
from a given point, P, multiply the Y coor- 
dinate times the maximum number of 
bytes per scanlines. This value will tell us at 
what logical row in memory the pixel is 
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located. From this location, the pixel will 
be at an offset X from the start of the row. 
Sounds a little confusing? Let's figure an 
example. 

Find the pixel location in VGA 
memory of P (109,47) in model3h: 

scanline = Y *320 = 47 *320 = 15040 = 

0x3AC0 
offset = X = 109 = 0x60 

pixel memory 

location = VGA memory ptr + scanline 
+ offset 
= A0000 + 0x6D + 0x3AC0 
= 0xA3B2D 

The code looks like this: 

unsigned int scanLine, offset; 
scanLine = Y * 320; 

// compute the scan line, Y 
*(BYTES/R0W) 
offset = X; 

// offset of pixel from scanline 
pVideoHem = (char *) (OxAOOOO) + scanLine 
+ offset; 

// ptr to pixel location 
*pVideoMem = pixelValue; 

// assign a value to the pixel 

Figure 2 shows the pointer arithmetic 
and point coordinates for thisexample. 

N avigating mode 13h is easy. N ow 
with the understanding of how a chained 
linear bitmap works, we can apply what we 



know to unchained planar memory, such 
as mode X. The important thing to keep 
in mind is that mode X scanlines are not 
320 bytes per row. M ode X is 
unchained— the bytes are organized across 
four planes of memory. So a mode X scan 
line now has (320 bytes/scan line) / 4 
planes =80 bytes/ scan line plane. 

The computation of a scan line in 
mode X, using the example P(109, 47) 
looks like: 



outp( MISC.OUTPUT, 0xe3 ); 
output SEQC.INDEX, 0x0300 ); 



} 



scanLine = Y * 80; 
// mode X scan line 

Figure 3 shows the pointer, planes, 
and points in modeX. 

This value is useless unless we can 
tell the VGA which memory plane this 
scan line corresponds to. The plane can 
be determined by playing a few games 
with the X coordinate using logical 
operators: 

X = 109 = 0x006D = 0000 0000 0110 1101 

W e want to filter and mask out the X 
value: 

X = 109 0000 0000 0110 1101 

k MASK = 255 k 0000 0000 1111 1111 

Result= 109 0000 0000 0110 1101 

T he operation is very uneventful and 
is in place only to act as a bit filter. W e 
want to be certain that we accurately grab 
the low order eight bits. Actually, the low- 
order two bits are the only ones of concern 
because these will reveal which memory 
plane this scanline belongs to. M asking out 
the plane is also accomplished with a logi- 
cal and operation. 



// select 25 Mhz dot clock and 60 Hz scan rate 
// restart the sequencer 

retrace end register 
ite protects 

total 

bit 8, vert counts 
louble scan 



ilayed 
le off 
start 
md 

iyte mode 



Listing 3. Setting Mode X with the Watcom 10.0 Compiler 



void setBodeX(void) 
{ 

setVideoHode(0xl3); // set the bios supported video mode 13h 

output SEQC.INDEX, 0x0604 ); // disable chain 4 mode 

outpwt SEQC.INDEX, 0x0100 ); // reset, stop the sequencer 



outptCRTC.INDEX, 0x11 ); // vertical 

outptCRTC.INDEX + 1, (inptCRTC.INDEX + 1) k 0x7f)); // remove wi 



outpwt 


CRTC 


INDEX 


outpwt 


CRTC 


INDEX 


outpwt 


CRTC 


INDEX 


outpwt 


CRTC 


INDEX 


outpwt 


CRTC 


INDEX 


outpwt 


CRTC 


INDEX 


outpwt 


CRTC 


INDEX 


outpwt 


CRTC 


INDEX 


outpwt 


CRTC 


INDEX 


outpwt 


CRTC 


INDEX 


outpwt 


SEQC 


INDEX 



VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 
VALUE. 



VERTICAL.TOTAL ); 
OVERFLOW ); 
MAX.SCAN.LINE ); 
VERT.RETRACE.START ); 
VERT.RETRACE.LOU ); 
VERT.DISPLAY.END ); 
UNDERLINE.LOCATION ); 
VERT.BLANK.START ); 
VERT.BLANK.END ); 
HODE.CONTROL ); 



// vertical 
// overflow. 
// set for ( 
// vsync st< 
// v sync er 
// vert dis| 
// dword mo< 
// v vblank 
// v blank 
// turn on 



i 
I 



// enable writes on all four planes 
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Figure 3. Pointers, Planes, Points, and Mode X 
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planes to 3. Setting 
bit allows write 
operations by the 
CPU to memory 
plane 0. This behav- 
ior is identical for all 
four bits in the Map- 
Mask register at index 
02h. 

The code for 
this operation looks 
likethis: 

nPlane = (x & OxOOff) 

& 0x03; 
/* calculate the 
plane from the X 
coordinate*/ 
regs.u.ax = 0x0100 + 

0x02; 

/* set the index to 
02h and initialize 
bit for pixel's 
plane*/ 



T here are four planes ordered to 3: 



PLANE MASK = 3 
0011 



0x03 = 0000 0000 0000 



Pay careful 
attention to the last 
line of code. T his is 
not computing an 
index into the 
sequence controller. 
It's actually a clever 
scheme to initialize 
the ax register before 
calling the outpuO 
function. The low 
byte, al, is being ini- 
tialized to the index 02h, the MapMask regis- 
ter in the sequence controller. The high 
byte, ah, is being initialized to set bit 1 of 
the MapMask register: 



Result = 109 0000 0000 0110 1101 

k PLANE MASK= 3 & 0000 0000 0000 0011 

Plane = 1 0000 0000 0000 0001 

This operation tells us which plane of 
display memory we are going to write a 
value to. The sequence controller MapMask 
register needs to be instructed which plane 
this is to allow the C PU to carry out a 
write operation on this memory. T he Map- 
Mask register is an 8-bit register, and only 
the four low-order bits, to 3, are of any 
significance. Bits to 3 correspond to 



regs.u.ax = 0x0100 + 0x02 = 0x0102 = 

0000 0001 0000 0010 
index of Map Mask register = AL = 0000 

0010 

initialize pixel plane to 1 = AH = 0000 
0001 

The value in AH is then shifted left 
nPlane times. This value will be loaded into 
the MapMask register to enable a write to the 
desired plane of video memory: 

regs.h.ah = regs.h.ah « nPlane; 



// set the bit for the pixel's plane 
outpw( SEQC.INDEX, regs.u.ax ); 
// set Map Mask to enable write 

The write to the memory plane can 
now be performed in the familiar manner. 
T he one exception to this operation is that 
X is no longer a linear mapping. T he offset 
is now atX/4. So: 

scanLineOffset = (y*80) + (x»2); 
pVideoMem = (char*)(0xA0000 + 
scanLineOffset) ; 
♦pVideoMem = pixelValue; 

T hat's it for writing a pixel to a mode 
X planar memory location. You can now 
port your old mode 13h line drawing and 
graphics libraries over to mode X. The 
complete listing isshown in Listing 4. 

By now, both my colleague and I had 
had very little sleep but we were eager, 
nonetheless, to test this unearthly technol- 
ogy. W e loaded up a laptop and drove out 
to a dry lake bed in the N evada desert 
where we executed the following test pro- 
gram. T he test was short. W e merely pow- 
ered up mode X, threw out a rectangle on 
the laptop's display, and powered it down. 
I can attest to the fact that my adrenaline 
was racing, for we had no idea what mode 
X would do, nor to the destructive power it 
was capable of. The test was successful, 
and as UFOIogist Bob Lazar would say, 
uneventful. The source code used at the 
N evada test site is shown in L isting 5. 

Copying Linear Bitmaps to 
VGA Planar Memory 

M y scientific colleague made some good 
assumptions about how to use mode X, 
but it was my radical cyberpunk anarchist 
friend who made the most astounding 
contributions. Based on the frequency of 
cattle mutilations per year divided by the 
rate that the giant stone heads on Easter 
Island creep toward the sea, the following 
piece to the big puzzle came to light. A nd 
I quote, 'This technology could be radical- 
ly applied to games, dude!" W hat revela- 
tion had my reality- twisted friend stum- 
bled upon? W hat could this possibly 
mean? A nd why did he have a "L inux 
I nside" sticker stuck to his tower case? 
Plotting pixels is okay for tinkering 
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with mode X, but let's face it, we want to 
get down to some serious business G ames 
must have cool backgrounds and sprites, 
right? The only way this can be accom- 
plished is if .PCX and .IFF files can be 
loaded into display memory. These files 
are typically decoded into memory and are 
suitable for a display mode like 13h. N ow 
you're going to learn how you can expand 
your horizons and your graphics library at 
the same time. T he goal here is to write a 
useful tool that takes the decoded graphics 
image from linear memory and writes it to 
display memory for use with modeX. 

A good starting point is to identify 
the differences in linear memory and VGA 
planar memory. A Deluxe Paint LBM 
image in memory is a 320- by-200 pixel 
bitmap with 256 colors. Describing this 
image in rectangular terms we have: 

• Left =0 

• Right =320 

• Top=0 

• Bottom =200. 

Images are commonly described in 
terms of logical rectangular coordinates. I n 
actuality, they are stored as chunks of 
memory, where their scan lines are stored 
consecutively, one right after the other. For 
the programmer and game designer, it is 
simpler to maintain descriptions of images 



Listing 4. Plotting a Pixel in Mode X 



in terms of the rectangular boundaries. It is 
easy to determine physical memory attrib- 
utes of a source image from a descriptive 
bounding rectangle. Using the example of 
a Deluxe Paint II image, the physical 
attributes of memory can easily be 
retrieved. This pseudocode calculates the 
number of bytes per scanline and starting 
offset of the image in the chunky bitmap: 

unsigned int srcBitPlapWidth, left, top, 

right, bottom; 
srcBitPlapWidth = right - left = 320 -0 

= 320 

srcOffset = (srcBitPlapWidth * top) 
+ left = (320 * 0) + = 

T hese are precisely the values we 
would need if we were to write this bitmap 
to VGA mode 13h memory. In fact, all 
that's needed from here is a pointer to 
VGA memory and a pointer to the source 
image. The entire image could simply be 
blasted to the screen with a call to strcpyO 
because the source is 320 by 200 bytes and 
so isthe destination VGA memory. 

That's basically all we would have to 
do if we were working in video mode 13h. 
H owever, we're working with mode X. 
We must now calculate a destination 
bitmap based on four memory planes. The 



Listing 5. Test Site Source Code 



((include <stdio.h> 
((include <stdlib.h> 
((include <conio.h> 

((include "modex.hpp" 

void mainO 
{ 

unsigned int i; 

setnodeXO; 

for (i=0; i<240;i++) 
{ 

writePixelModeX(0,i,0x23); 
writePixelModeX(319,i, 0x23); 

} 

for (i=0;i<320;i++) 
{ 

writePixelModeXU, 0,0x23) ; 
writePixelModeXU, 199, 0x23); 
writePixelModeXU, 239, 0x23); 

} 

getchO; 

setVideoMode(0x03); 

printf ("done. . . press any key to 

continue\n"); 

} 



difference between the source image mem- 
ory and destination video memory is that 
the image is stored in linear memory, and 
the destination is planar video memory. 
ur task is to devise a means to map a 
chunky bitmap in memory to four VGA 
memory planes. 

The description of the source image 
in terms of srcBitPlapWidth and srcOffset 
needs no further attention. This is all the 
information, including the image srcPtr 
itself, we will need to map the chunky 
bitmap. Similar descriptions are needed for 
the destination memory. The destination 
bitmap width for VGA plane memory is 
simply the source bitmap width divided 
among four planes of VGA memory. 
W ith the value of srcBitPlapWidth, dest- 
BitHapWidth and destBitPlapOffset can be 
computed as follows: 

destBitMapWidth = srcBitPlapWidth / 4 
destBitMapOffset = (destBitMapWidth * 
top) + (left/4) 

If you're still in the game here, you've 
determined by now that this information 
sheds no light as to which plane of memo- 



// plot pixel in mode X 
((define BYTES_PER_SCAN_LINE 80 
((define BAP_HASK 0x02 
((define INITIAL_PLANE_BIT 0x100 

((define MAP_MASK_PLANE_INIT INITIAL_PLANE_BIT + HAP.HASK 
((define BIT_FILTER_BASK OxOOFF 
((define HAX.PLANEJ 0x03 

void writePixelHodeX( unsigned int x, unsigned int j, char pixelValue) 
{ 

union REGS regs; 
char *pVideoMem; 
char nPlane; 

unsigned int scanLineOffset; 

nPlane = 0; 
scanLineOffset = 0; 

scanLineOffset = (y*BYTES_PER_SCAN_LINE) + (x»2); 
nPlane = (x ft BIT_FILTER_HASK) ft MAX.PLANEJ; 

regs. w. ax = MAP_HASK_PLANE_INIT; // set index 02h, and initialize plane = 1 

regs. h. ah = regs. h. ah « nPlane; 

outpw( SEQC.INDEX, regs. w. ax ); 

pVideoMem = (char*)(0xA0000 + scanLineOffset); 

♦pVideoMem = pixelValue; 

} 
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ry we are to enable CPU writes to. Recall 
from the earlier discussion of plotting pix- 
els in mode X that the X coordinate was 
the key in unraveling the mystery of which 
plane is to be write enabled. Well, the 
bitmap doesn't have an X coordinate 
or.. .does it? Simple high school geometry 
proofs showed that a rectangle can be 
described by two points: Pl(xl, yl) and 
P2(x2, y2). T he bounding rectangle of the 
bitmap is defined by two points. T hey are 
Plfleft, top) and P2(right, bottom). The 
left boundary is what we'll use to deter- 
mine the initial plane to write enable: 

char nPlane, planeMask; 

nPlane = left ft 0x03; 

left = 0000 0000 0000 0000 

Si mask = 0000 0000 0000 0011 

nPlane = 0000 0000 0000 0000 = 

planeMask = 0x11 SHL nPlane = 0001 0001 
« = 0001 0001 

By performing a logical AND operation 
on the left coordinate with the mask 0x11, 
we can determine the initial plane we need 
to enable. Play around on paper and shift 
the bits Oxll about two or three times. 
Computing the initial plane is significant 
for two reasons First, you do not need to 
have a rectangle that's 320 by 200 or starts 
at left =0, top =0. Second, this initial 
value will come into play later, for cycling 
the planes to write enable. 

But that's coming up, and let's not 
get ahead of ourselves W ith this informa- 
tion in hand, we now know the plane for 
the first destination pixel. The following 
code does this: 

nPlane = left k MAX.PLANEJ; 
planeMask = 0x11 « nPlane; 

The first plane is now calculated, but 
not yet enabled. We must loop through 
the entire chunky bitmap image in memo- 
ry and write it to the proper VGA memory 
planes. This will require a nested loop — 
the outer loop will walk the rows of the 
linear bitmap, and the inner loop will han- 
dle translating the linear image scan lines 
to the VGA memory planes. The 
pseudocode is shown in L isting 6. 

This code resembles a brute-force 



mode 13h blitter. The exception is the 
initialization of register bitsROLplane 
with the current planeMask value we com- 
puted earlier. T he code then drops inside 
to the nested loop where a miracle 
occurs Rectwidth - 1 times. 

N ow what's so miraculous about the 
inner loop? It needs to do several things: 

• E nable the desired plane for a write 
operation 

• Change the plane for the next pixel 

• C opy the source image pixel to the 
proper VGA plane memory location. 

T he first step is simple and is already 
included in the pseudocode in Listing 6. 
T he plane, as you already know, is enabled 
by setting the proper bits in the MapMask 
register of the sequence controller. That's 



Listing 6. Pseudocode for a Nested Loop 



RectWidth = right - left; 
nRous = bottom - top; 



why the outpO function call is in the inner 
loop. The second step, involving changing 
the plane for the next pixel is not so easy. 

I nstead of computing the plane by 
looking at the current offset, we will 
approach the problem from a simpler 
angle. T he plane to be enabled is cyclic by 
design. T hat is, if plane 2 is being enabled 
for a write operation, the next plane to be 
enabled after the write is plane 3. After 
plane 3 has been written, we need to wrap 
around back to plane 0. W e already know 
the initial plane to enable. We calculated 
this earlier. T his value will initiate the 
cyclic sequence. By taking this initial value, 
planeMask, we can determine the next plane 
to be enabled by performing a R0L opera- 
tion. You can access an example of this 
cycle on the G ame D ev eloper ftp site 
(ftp://ftp.mfi.com/gamedev/pub/src). 



I n the final R0L operation on the 
planeMask, the bit in nibble 7 moved left 
out of the byte and set the CPU CarryFlag. 
In a ROL operation, when the CarryFlag is 
set, the bit that rolled out of nibble 7 rolls 
back into nibble 0. T his emulated ROL 
operation on the planeMask bits provides a 
simple mechanism for cycling the planes to 
write enable. T he only drawback is that ROL 
operations are not provided in the C 
library function calls or by any binary oper- 
ators. So we need to write one ourselves: 

unsigned int bitCarryFlag = 0; 
char bitsROLplane = planeMask; 

T he operation of performing a ROL on 
a byte value can be accomplished by using 



the C and C -H-shift left operator, «. This 
will perform a bitwise shift left, but will 
not indicate when a bit set in nibble 7 has 
shifted out to the left: 

bitsROLplane = bitsROLplane « 1; 
// shift bits left once 

The bitwise shift left is basically the 
SHL operator. nee the bit has shifted out 
of the high nibble, it falls into the bit 
bucket never to be recovered. We must 
manually check the bit in nibble 7 before 
the logical shift operator is used. T he nib- 
ble can be examined with a mask opera- 
tion, which we'll use to mimic a CarryFlag 
when the bit shifts out of the byte. The 
following example illustrates a case where 
plane 3 wraps around to plane 0, based on 
the result in the bitCarryFlag: 



outp( SEQC.INDEX, HAPJASK ); 
for(rows=0; rous<nRows; rows++) 
{ 

bitsROLplane = planeMask; 

for(scanlines=0; scanlines<RectWidth; scanlines++) 
{ 

outp( SEQC.INDEX + 1, bitsROLplane ); // enable desired plane for a write 
A miracle occurs here... // occurred sometime after the 7th day 

} 

pVideoHem ♦= destBitMapWidth; 
SourcePtr += srcBitHapWidth; 
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bitCarryFlag = bitsROLplane & nibbleMask; 

bitsROLplane = 10001000 
nibbleHask= & 1000 0000 = 0x80 
bitCarryFlag = 1000 0000 = 0x80 

Now perform the logical SHL opera- 
tion on bitsROLplane: 

bitsROLplane « 1 = 0001 0000 

T his is the condition we need to test 
for to wrap the plane back to zero. W hen 
the value in bitCarryFlag is equal to 80h, 
the plane will wrap. This test carried out in 
the following manner: 

if (bitCarryFlag == 0x80) 
urapPlane; 

W hat precisely does it mean to wrap 
the plane? The value 0x80 is a bit filter to 
alter the contents in bitsROLplane to fit the 
cyclic model. T he wrapping around occurs 
by performing a logical OR operation on 
bitsROLplane: 

bitsROLplane = bitsROLplane I 0x01; 
bitsROLplane = 0001 0000 
OR 0000 0001 

bitsROLplane = 0001 0001 

That's the whole tamale for plane 
wrapping. It's not so difficult once you've 
walked through it. The code for perform- 
ing this operation looks like this: 

bitCarryFlag = 0; 

bitCarryFlag = bitsROLplane & 0x80; 

// test for non-zero high order nibble 
bitsROLplane = bitsROLplane « 1; 

// set mask for next pixel's plane 
if (bitCarryFlag == 0x80) 

// if high order nibble non-zero 
bitsROLplane = bitsROLplane I 0x01; 

// carry the bit to louest nibble 

Thethird and final dilemma we need 
to resolve is mapping linear bitmap bytes 
to the corresponding VGA planes. The 
outer loop controls what row is being 
updated on both the bitmap and the VGA 
memory. The inner loop is walking the 
scanlines T his is simply moving to the off- 
set from the start of the scanline and 



updating each pixel in the bitmap to the 
designated plane of memory from the ROL 
operation. 

T ranslating offsets in mode X mem- 
ory is simple. Remember that we treated 
the X coordinate in the earlier examples 
as the offset in memory. T he coordinate 
X, or the offset, mapped to a VGA plane 
at offset X/4. T he mapping of a byte from 
a chunky bitmap to a defined VGA plane 
of memory is the same. T ranslating pixels 
is accomplished by the following code 
snippet: 

pVideoMem[scanlines»2] = 
SourcePtr[scanlines] ; 

The pointer pVideoMem is referencing 
the VGA memory plane, and SourcePtr is 
referencing the byte to be mapped. The 
index, scanlines, is byte offset in memory 
from SourcePtr of the pixel to be mapped: 

pVideoMem[scanlines»2] = 
SourcePtr[scanlines] ; 

Trust No One 

N ow you have enough information to be 
dangerous. N o longer can the assembly 
language listings in M ichael A brash's The 
Zen of Graphics Programming (Coriolis, 
1994) be of any threat to you. If you don't 
have this book yet, buy it! A brash gave 
away all the industry secrets in one book. 
A s I mentioned, the source code is old, real 
mode 8086 code, and requires some atten- 
tion when porting it to Watcom protect- 
ed- mode compilers 

As I paced the small apartment of my 
cyberpunk anarchist friend, my deep prob- 
ing meditations were disrupted by a stereo 
tone from the Sound Blaster 16 card of his 
computer, signalling the succesful end of a 
compile. 

H e had compiled the linear bitmap 
translator and was ready to execute it. 
Time flowed in slow motion as I ran 
towards him, shouting, "N ooo!" M y hands 
reached out to stop his right index finger as 
it glided over to tap the enter key on his 
keyboard. 

H is head turned slowly, grinning like 
some sinister goblin, his eyes hidden 
behind round purple reflective lensed 
cyberpunk sunglasses. T he words rolled off 



his tongue with no concern to their 
impending dangerous implications 

"Rock and roll, dude!" he said, and 
his finger pressed the enter key. I froze in 
my tracks as the computer set the alien 
mode and wrote the bitmap in system 
memory out to the mode X display. M y 
heart pounded harder and shorter than it 
did out in the Nevada desert. I looked at 
him, my facial expression scorning him for 
being so technically irresponsible. The 
consequences could have been far worse. 
The thought that raced through my mind 
was that mode X could somehow chaoti- 
cally react with our atmosphere and burn 
up all the oxygen. But that didn't happen. 

"W hoa, dude," he said. "Check it 
out— we're all still here." H is hands 
pressed firmly against the chest of his tie- 
dyed t- shirt. H e wanted to make certain 
that the molecular organization of his body 
was still structurally intact. H egot up from 
his chair and pulled back the curtain. 
"Excellent!" he nodded, 'The time contin- 
uum seems to be in order as well." 

This test somehow alerted the boys 
from Big Blue. A network tap started to 
set off an alarm. T hey were getting a fix on 
our location. The anarchist cyber dude 
started scrambling his IP octets to confuse 
the people tracking his network routes and 
hops. 

"Until we can finish constructing our 
They Live VR visors, no one is safe," he 
gravely stated. 

D ue to space constraints,! couldn't 
list all the code necessary to this encounter. 
You can access the complete listing for 
copying a chunky bitmap to VGA modeX 
planar memory and the code used in the 
test by the cyber dude on the Game Devel- 
oper ftp site. 

All I can say for now is, watch out. 
M ode X works— on W indows 95, too, in 
protected mode. M aybe Redmond is 
where we'll find them. You don't have to 
believe me, see for yourself. M ode X is out 
there and it's in your system. ■ 



M ichael J. N orton holdsa B.S. in physics 
and hasworked asa programmer for 12 years 
H e is currently working on a book for pro- 
gramming theW indows 95 SD K. 
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Gamin' for 
Grrrrls 



Barbara Hans come 

How hove some gome 
companies fried to 
oppeol to girls? Are 
these gomes vastly 
different from those 
designed for o more 
general audience? 
And horn? 



Mow do we make games girls 
and women will buy? I t's a 
question today's game compa- 
nies must ask themselves or 
lose out on a little more than 
half the potential electronic 
entertainment market. M ost 
game industry executives seem 
to conclude that if they are to consider 
targeting girls and women at all, it will 
not be at the risk of excluding their core 
market of boys and men, which is why 
games for kids are often touted as being 
"gender inclusive." But what does gender 
inclusive mean, exactly, and is it the most 
effective way to attract the female mar- 
ket? G ame industry pros have conflicting 
opinions. 

Some feel that the games claiming 
to be gender inclusive really aren't, and 
that all thistalk of gender- inclusivity just 
perpetuates serving the needs of a male 
audience. "Until the day when 'gender 
neutral' stops meaning 'really boys,' I 
truly believe that we have to create games 
specifically for girls," says cartoonist 
Trina Robbins, who wrote and designed 
Sanctuary W oods' interactive CD-ROM 
H awaii H igh, M ystery of theTiki. 

If you look at some of the research 
into gender differences, the idea of a gen- 
der inclusive game seems like a diffi- 
cult—if not impossible— goal to reach. A 
1984 edition of Personal Computing 
Teacher features a study "Situational 
Stress as a Consequence of Sex-Stereo- 
typed Software," which states that if you 
take games with the characteristics girls 
like and make boys play it, boys show 
signs of situational anxiety and their per- 
formance and focus deteriorates. The 
study claims girls have the same reaction 



when playing with "boy" software. (At 
the same time, a common belief exists in 
this industry that girls will play "boys' 
games," but boys will not play "girls' 
games"— an attitude that can't do much 
except tilt the scales toward the tastes and 
preferences of males.) 

Still, game developers are cautious 
about stereotyping and generalizing gen- 
der differences in game preference and 
play. "If we say 'girls don't like violence 
so we'll give them Barbie D oils' or ' girls 
want story, so we won't let them play 
Sonic the H edgehog,' we're creating par- 
adigms of exclusion for both boys and 
girls," says M argy G ilman, an interactive 
TV producer in San Diego. "I t's just as 
discriminating to boys [to give them only 
violence] and not to give them story and 
character. T here are lots of boys who care 
about that." 

C reative W onders is also cautious 
about excluding boys. Its new title M ade- 
line and the M agnificent Puppet Show 
boasts a famous female heroine chosen for 
her pluckiness and popularity with girls 
and women from the storybooks of Lud- 
wig Bemelmans. But C reative W onders 
says M adeline is not a game "for girls," 
but a game for children that girls "espe- 
cially" will like. Even the Women's Inter- 
active Entertainment Association has 
taken a stance supporting "gender inclu- 
sivity" over "gender specificity." "It's not 
about making gender specific titles," 
explained W I EA president Valerie H en- 
nigan. "It's about making them 'gender 
friendly'.. ..and it's marketing those games 
to girls. Interactive entertainment isn't 
even marketed to females." 

W hile the discussion continues 
about how to best reach girls and 
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women— be it with an affirmative action 
approach or with gender inclusive games 
for boys and girls— this installment of 
Chopping Block takes a look at a few 
titles for children and what characteristics 
might make them appeal to girls (and in 
some cases, to boys as well). 

Sega and Nintendo Games 

M uch of the research into girls' game 
preferences suggests that what many of 
the classic arcade, N intendo, and Sega 
style games are made of (repetition, scor- 
ing, speed, violence, target shooting, time 
limits, reinforcement based on skill 
instead of effort) is unappealing, boring, 
and senseless to girls. 

In 1994, Sega introduced Crystal's 
Pony Tale, a game designed to attract 
girls aged four to seven to the Sega plat- 



form. T he game was created by Sega's all- 
women G irlsT ask Force to be a girl's first 
Sega game— and in many ways that is 
exactly what it is (kind of a Sonic the 
H edgehog with pink training wheels.) 

In C rystal's Pony Tale, Crystal's 
friends have been kidnapped by a wicked 
witch and hidden throughout the game. 



Players must help C rystal find seven crys- 
tal shapes to free her pony pals from cap- 
tivity. U sing the Sega keypad, players help 
Crystal gallop and leap in the air and 
capture keys and horseshoes. T he horse- 
shoes let C rystal move to three other "lev- 
els" or environments in the game, and the 
keys let her open treasure chests, where 
crystals and clues can be found. T he hid- 
den ponies are marked in the game with a 
silhouette of a horse and the shape of a 
crystal. If Crystal has the correct rock in 
tow, the player can move C rystal next to 
the pony's shape, press the action key, and 
releasee rystal's friend. 

Crystal must collect the right num- 
ber of horseshoes before she can pass into 
the next environment, but the game isn't 
based on scoring or attaining the next 
level as much as it is on helping Crystal 



help her friends— a goal a four- year-old 
girl might find more worthwhile than 
shooting at a target. W hen Crystal suc- 
ceeds in doing this, hearts of love and 
gratitude spring forth from her pony 
friend onto Crystal's head. It's corny, but 
the positive feedback can't be ignored. 
Still, you certainly wouldn't call 



C rystal's Pony T ale a "story- driven" 
game— and research indicates that girls 
are more interested in story lines than fast 
action. C rystal's Pony T ale follows the 
sametried-and-true, linear action formula 
of any Sega title. T he "story" is more akin 
to a game "theme." 

The game is slower paced than your 
typical Sega or Nintendo action adven- 
ture. There is no time limit; Crystal can 
stop and talk to a cow in the barn, 
munch on hay, or sniff sunflowers with- 
out the threat of being bonked or killed 
by incoming villains. The player also has 
a game map of sorts, which enables 
Crystal to move between levels if she 
wants to. 

In keeping with research showing 
girls are more motivated by sound, voices, 
and music than boys, the game lets girls 
choose the background music at the 
beginning of the game from a number of 
classical pieces. 

As for violence, well, Crystal isn't a 
exactly Steven Segal, but she does exhibit 
some aggressive behavior. W henever 
C rystal tries to rescue a friend, the pastel- 
colored sky turns dark, the music picks up 
tempo, and the evil witch swoops onto 
the scene. If you continuously press the 
action key, Crystal rears on her hind legs 
and whinnies repeatedly. W ithout blood- 
shed or bullets, the witch disappears and 
serenity returns. 

C haracter involvement is crucial to a 
girl's enjoyment of a game experience, 
according to research. But we know very 
little about this pony. The players' guide 
tells us that C rystal is the "shyest" pony in 
the land, but if you don't read the guide, 
you miss out on this information (which 
might give some players a sense of 
accomplishment after helping Crystal 
overcome her shyness and fight the 
witch). 

Sega seems to prefer using animals 
in their gender- inclusive children's games 
instead of humans, perhaps because they 
are easier to gender- neutralize. In fact, 
Crystal could be either male or female; 
the character is so poorly rendered you 
can barely see its face. If I were a five- 
year-old girl and my big brother were 
playing a richly animated game like 
Earthworm Jim on our family Sega sys- 



WHAT DO GIRLS LIKE? WHAT DO BOYS L I E ? 



Industry and academic research reveal some interesting differences in what many 
girls find fun, challenging, and engaging in electornic entertainment. But of course, as 
you'd expect when dealing with human preferences and tastes, contradictions 
abound. Still, some of this research is hard to ignore. Here's a summary of some of the 
findings: 

• Females prefer utility, reality, and constructive goals, while males prefer aggressive 
and competitive themes and are less interested in the far-reaching benefits of a game. 

• Females find sound, especially voices, motivating, while males are often observed play- 
ing with the sound turned off. 

• Females are less interested in "games" (meaning play involving established rules, clear 
objectives, and the notion of winning) than other forms of play. 

• Females like interactive products without scoring or competition and are less interest- 
ed in winning. Males often mention scoring (and winning) when discussing games. 

• Females are flexible with rules and will change rules to suit a situation, while males are 
more inflexible with rules. They use rules to determine domination and enjoy following 
them. 

• Females are frustrated when having to start over from the beginning of a game. Males 
find this motivating. 

• Females are more confident, optimistic, and motivated when feedback focuses on effort 
vs. ability. They see feedback as a reflection of their ability and will question them- 
selves if the feedback is negative. 

• When feedback is based on effort, males see it as a reflection of poor performance and 
loose motivation. 
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tern, I'd feel a little slighted. 

Some girls, especially girls at the 
older end of the game's age- range, might 
find the Arthurian castles a bit tired and 
cliche. According to Sega, they set the 
story in this environment because 
research indicated girls like fantasy, but 
does fantasy really mean witches and gob- 
lins? It's no wonder many of them 
skedaddle on over to the more exciting 
world of Donkey Kong Country— a game 
popular with both girls and boys. 

Donkey Kong Country 

N intendo's Donkey Kong Country wasn't 
designed "for girls" or with girls in mind, 
but girls certainly like it. In a nationwide 
survey of 1,600 kids taken by interactive 
TV producer M argy G ilman, D onkey 
Kong was listed in the top five favorite 
games of girls (along with M ario Broth- 
ers, Sonic the H edgehog, Lion King, 
and— believe it or not— M ortal Kombat). 

The game takes players on a jungle 
adventure with two primates: Donkey 
Kong (a big macho ape) and his friend 
D iddy (a small, agile monkey). Your goal 
is to help them recapture their horde of 
bananas, which have been stolen from 
them by the evil Kremlings. You help 
Donkey and Diddy run and jump over 
obstacles, grab ropes and swing through 
the forest, even swim through water 
worlds capturing bananas, letters (that 
spell out Donkey Kong of course), and 
extra lives. You've got to move fast or any 
number of beasts will run you down. 
W hen you "lose a life," you start over 
from the beginning of the level; if you 
lose several lives in succession, you "die" 
and start over from the beginning. 

Going by the research into what 
girls like in games, there would be little in 
Donky Kong to get a girl hooked on 
video gaming. The game isn't based in 
reality; nor does it involve a story. (You're 
supposed to be helping Donkey and 
Diddy regain their hoard of bananas, but 
if you don't read the players guide, you 
don't know this or care.) G ame feedback 
is based on the number of points you 
score and the level you achieve— which 
research says girls find less motivating 
than feedback based on trying. So why is 
the game popular with girls? Could it be 



that a large number of girls out there 
enjoy the fast action, the funny anima- 
tions, and three-di mensionally rendered 
jungle worlds, and the challenge of attain- 




Unfortunately, Candy Kong, the only 
female character in Donkey Kong Country, 
serves as little more than a showpiece. 



ing points and mastering the levels? 

What I find disappointing in Don- 
key Kong is that the game features only 
one female character: Candy Kong, an 
ape in a hot-pink bathing suit with noth- 
ing better to do than pose provocatively in 
a booth and help D onkey and D iddy save 
their points. Basically, she's stuck playing 
Vanna W hite while the guys go out for a 
swingin' banana hunt. H umph! That's 
not very "gender inclusive." 

Another gripe: you're deprived of 
most of the game until you reach a certain 
level of skill. Donkey Kong contains 
seven environments and 40 levels. Each 
level is wonderfully different and features 
new obstacles and characters, which you'll 
never see unless you play the game well 
enough and score high enough to reach 
these levels. G ame developers I Ve spoken 
with call this setup "having to earn the 



game," and they say girls find this game 
plan more of a turn-off than blood spurt- 
ing from a corpse any day. 

Sure, girls can master the game just 
as well as boys can, but research suggests 
that they'll become bored (or frustrated) 
with the experience long before that will 
happen. 

Donkey Kong Country 2 coming 
out this D ecember, might have more "girl 
appeal." Girls might find the goal of the 
game more "worthwhile": you're actually 
trying to save D onkey Kong from capture 
by the evil Kremlings. But more impor- 
tant, it stars a female character (at last, a 
female saving a male in distress!). This 
game stars Dixie Kong, Diddy's little 
monkey friend, who sports a pink t-shirt 
and a long, platinum-blonde ponytail. 
Some might argue that she's really just 
Diddy in drag, but it's hard not to smile 
when watching her in action. Face it, 
she's cute. And she takes the lead 
throughout the game, dragging Diddy 
around and leaping above obstacles, her 
ponytail whipping about like a propeller. 
According to a N intendo spokesperson, 
the company hopes D ixie will be the next 
flagship character for the N intendo line. 

Hawaii High, 
Mystery of the Tiki 

Released in 1993, H awaii H igh, M ystery 
of the T iki, from Sanctuary W oods was 
one of the first interactive CD-ROMs 
created specifically for girls aged eight and 
up. H awaii H igh is more interactive story 
than adventure game, in keeping with the 
theory that girls like character and story 
more than fast action. It stars a teenager 
named Jennifer, who just moved from 
New York to H awaii, where her mom, a 
working professional, has taken ajob. She 
and her new friend M alaya are on an 
adventure to return a lost Tiki statue to its 
rightful place. H ot on their trail are two 
dastardly villains (a man and a woman— 
equally bad) who want the Tiki for its 
resale value on the black market. 

Trina Robbins, who wrote and 
designed the game, said she used the 
N ancy D rew mysteries for inspiration. 
Those stories, said Robbins contain the 
classic things many girls like. "Girls 
haven't changed; girls will never change. 
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We will always like adventure and prob- 
lem-solving." Robbins says she created 
two female protagonists because girls like 
to play together. She also wanted charac- 
ters that girls could relate to and who 
were a little older than the game's target 
market. "N ancy D rew was a teenager but 
it was much younger girls who read her 
books." 

An assumption game developers 
make is that girls like "fantasy," yet 
research states they like themes based in 
reality. H awaii H igh takes both into 
account. Robbins uses elements of fantasy 
and mythology in the game, but the story 
takes place in today's modern world— and 
Robbins provides real-life situations her 
players can relate to. For example, we 
begin the game on Jennifer's first day of 
school, where she faces a classroom full of 
beachniks in shorts. D ressed in N ew York 
City urban chic, it's apparent that she 
feels like an outcast, as anyone would in 
the same situation. 

L ike many interactive stories, H awaii 
H igh lets the players move at their own 
pace and interact with the environment. It 
also includes a "story map" that lets the 
player begin where she left off or "lost" the 
game. The things that work least well in 
the game, according to Robbins, are a few 
puzzles, which were thrown in by male 
programmers on her team to "make the 
game more exciting." In one, the player 
must maneuver the characters through a 
three-dimensional maze— an annoying 
interruption for any player, especially if 
she or he is trying to get to the next clue. 
Robbins says her gut feeling was that girls 
wouldn't like the puzzles because "they're 
closer to boys' twitch games." 

H awaii H igh's dress- up segment was 
criticized in the press, as was the choice of 
pink attire for one of the characters. Rob- 
bins calls such criticism "throwing the 
baby out with the bath water" in an 
attempt to avoid sexism. "G iris do wear 
pink, and I felt that it was one of the per- 
sonality traits of this particular girl to wear 
lots of pink. T he other girl character wears 
bright reds and blues." A s for the dress up 
game: "G iris like to play dress up. W omen 
do, too!" says Robbins. 

Women and girl protagonists, espe- 
cially in preteen adventures, are also prone 



to romance. Robbins purposely kept this 
to a minimum. "It's really the idea of 
romance that they like. At that age, most 
girls think little boys are horrible. G iris 
are much more interested in interaction 
between females." She took care of the 
romance issue with a scene in which Jen- 
nifer watches a cute boy play the ukulele 
and sing, while little hearts dance over her 
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head. "Requisite romance taken care of," 
explains Robbins, "back to the girls!" 

Chop Suey 

C reated by writer T heresa D uncan and 
artist M onica G esue with the idea of cre- 
ating a C D -RO M girls would like (but 
not a "game for girls," per se), C hop Suey 
from M agnet I nteractive and 20th C en- 
tury Fox isn't easy to define. It's neither 
game (no action, no rules, no scoring) nor 
interactive story (there's no beginning, 
middle, or end), nor creative activity pro- 
gram. You might call it an "interactive 
poem." T he C D -RO M combines hip, 
engaging art, with melodious, alliterative 



prose read by National Public Radio's 
David Sedaris (who was selected for the 
job, according to M agnet, for his androg- 
ynous voice). I n fact, if you were to give it 
edutainment value, it would be that it 
shows the beauty and power of words. 

Duncan said she modeled the game 
after classic children's literature such as 
M aurice Sendak's Where the Wild Things 
Are. She said she didn't pay much atten- 
tion to research, but "designed it from the 
heart." Chop Suey features two sisters: 
L ily and June Bugg, who livein Cortland, 
Ohio. In the first scene, all we see of 
them are their legs and anklette socked 
feet— one sister's legs are brown, the 
other's are white. Other than that, we see 
little of them throughout the game, since 
we experience everything from their point 
of view. T he two girls have just gone 
shopping for red licorice at a candy store 
called Cupid's Treats and eaten chop suey 
with their father at the Ping Ping Palace. 
They're lounging in the grass, watching 
clouds pass overhead and trying to make 
sense of their shapes. 

Soon, we're floating above a colorful 
map of Cortland, and the city is our oys- 
ter. We can explore the Carnival, Aunt 
Vera's H ouse, C upid's T reats, and several 
other spots on the map. nee we venture 
forth, we can return to the map with a 
click of the mouse— we're not going to 
get caught in a puzzle or a maze where we 
can't escape. 

T he "story" comprises memories and 
moments in a few character's past and pre- 
sent lives. We're voyeurs sneaking into 
bedrooms, peaking through windows, and 
rummaging through drawers. In Aunt 
Vera's room, her life unfolds asjune Bugg 
and L ily remember things she's said 
before, embellish her stories, and fantasize 
about her adventures (And none of these 
fantasies involves castles or witches, by the 
way.) W e discover M iss Vera's life is "a 
long series of magical stories, like shiny, 
dull pearls on a long, long, necklace." Vera 
is a former Rockette who lived in N ew 
York C ity. C lick on a picture on the wall 
and learn about her three ex- husbands (all 
named Bob). One Bob lives on the edge 
of town and still sends her "roses of the 
palest pink." Click on the matchbook 
cover on her bureau and go to a nightclub 



56 GAME DEVELOPER - OCTOBER/NOVEMBER 1995 



CHOPPING BLOCK 




called the Single Spotlight, where a 
lounge singer performs a sad love song. 

Even better, you can snoop in a boy's 
room. I n this case it's Vera's teenage son, 
Dooner, a rock and roll musician with a 
motorcycle and a silk aviator scarf, who 
"used to sing songs about girls named 
Lurlalou, or Pitapat, or just plain M ary." 
Dooner sits on his bed amidst record 
album covers and bags of "Fame- On!" 
chips, oblivious that you're rifling through 
his bedroom drawers. W e find a maga- 
zine called Girly (which we can't read) 
and his diary (which we can read), reveal- 
ing an account of his date at the carnival 
with a painter named M onica. 

In this game, at the picnic scene 
(where you watch A unt V era dance with 
an E Ivis Presley look-alike named Ned), 
a lawnmower buzzes in the background, 
birds sing, wind chimes jingle in the 
breeze, and a dog barks. (If you pick up 
x-ray sunglasses at the bottom of the 
screen, you'll see Vera and her current 
beau in their underwear!) 

For those who enjoy dress-up 
games, you have a few options to choose 
from. You can raid Aunt Vera's closet. 
Click on a long, red evening gown and 
see A unt Vera lounging languidly in a 
hammock, a bowl of fruit on her lap. You 
can also dress up a drooling rambunctious 
dog named M ud Pup in loud boxer 
shorts, socks, and a shirt, while punk rock 
bounces in the background. In another 



segment, you put eyelashes, sunglasses, 
and a goatee on a woman's face. 

C hop Suey isn't based on scoring or 
fast action, but on a mood, style, and 
sense of humor that kids and adults can 
enjoy. W hile the gender stereotyped 
experiences of romance and dress- up 
might sound corny, these elements are 
handled in a humorous, fun way. It's clear 
that Chop Suey appeals to a different 
sense of play— one based on exploration 
instead of target shooting and violence, 
one that delivers entertainment value 
from humor, characters, and the beauty 
and power of language and art. This 
defies the traditional "game" experience 
that boys seem to like so much, but isthis 
type of computer play something that 
only girls can appreciate? 

Elroy Goes Bugzerk 

E Iroy G oes B ugzerk from H eadbone 
Interactive is another story-based game 
that boys might enjoy as well as girls— if 
not more so. The CD -ROM is billed as a 
"comic adventure for kids aged 7 to 97" 
and features a boy named Elroy and his 
dog, Blue, who are hunting for a rare 
stink-bomb-dropping beetle called the 
Technoloptera, in the hopes of winning 
their city's annual Insectathon. 

This game's protagonist is all boy. 
H e loves scatological humor (in one scene 
he enters a cave of locusts and comes out 
covered in locust poop). H e's loud, he's 



sarcastic— but he's vulnerable, too. It's 
clear that E Iroy is in a predicament: if he 
doesn't catch the beetle by the end of the 
weekend, he's going to lose the Insec- 
tathon and his nemesis, the evil Gordon 
Smugs, will win. It's your job as the player 
to help him. 

T he game features long stretches of 
animated action with few chances to use 
the mouse. Eventually, the story stops, 
Elroy asks you what he should do, and 
you tell him by clicking your mouse. Your 
actions usually involve telling E Iroy to go 
one direction or another, exploring ele- 
ments in a room, or choosing from a list 
of options, but most of them require some 
thinking. You need to use what you learn 
throughout the game (such as information 
about insects) to determine Elroy's— and 
thewisecrackingtech n ol optera's— fate. 

L ike C hop Suey, E Iroy relies on 
story and character as well as its own style 
of cornball humor. These elements lean 
toward stereotypic "male" preferences, 
which might turn off some girls. But the 
style of play lends itself to a wide range of 
characters and story elements— just as 
Chop Suey does Adding a female heroine 
to Elroy's story could make the game 
more appealing to girls, especially if she's 
an important character who girls can iden- 
tify with— and not just a "token" show- 
piece. According to H eadbone, Elroy will 
get a female sidekick in the next title. 

Appealing to the huge range of play 
preferences that girls and boys have is a 
great challenge for game developers, and 
one that might seem daunting. H owever, 
as interactive entertainment designer 
H eidi D angelmaier puts it, "G ender is not 
a burden to bear but an intriguing human 
dynamic that can bring texture and pas- 
sion to interactivity." To reach girls and 
women with electronic entertainment 
(and a new audience of boys and men), it's 
obvious that game developers need to con- 
sider new directions in computer play. 
Addressing different preferences and 
styles in gameplay (be they gender influ- 
enced or not) will make those new direc- 
tions more interesting and exciting— for 
male and female gamers alike. ■ 

Barbara H ansrome is managing editor 
of Software D evelopment magazi ne. 



58 GAME DEVELOPER - OCTOBER/NOVEMBER 1995 



Back 




H R T 



E W 



Void Pirates 
on Parade 



David Sieks 



Developing a visually 
exciting gome lakes 
more than the right 
design tools. Hard 
niorh. capital, and 
actors mho'll mork for 



beer are all 



Digital entertainment has come a 
long way since Pong was able to 
captivate us for hours on end. 
As the technology has grown, 
so has the scope of game devel- 
opment. The digitized faces of 
big- name stars have taken the 
place of humble sprites, story- 
lines are assembled by herds of suits, and 
graphics and programming are farmed out 
to production houses in faraway countries. 
I n such big- stakes projects, C reative C on- 
trol isan elusive bird: once the cage door is 
opened, off it flutters. .and it doesn't come 
back when you whistle. 

But if you're starting to think "I 
Did It M y W ay" is a tune no longer 
heard in the game industry, you should 
listen more closely to that humming 
sound emanating from Ian Firth. Firth is 
putting the finishing touches on Void 
Pirates from D iversions Software and 
SofSource I nc. I recently had the chance 
to ask him some questions about the 



project, and because I like you I II let you 
in on what he had to say: 

GD: Give us a little background: what is 
Diversions Software, what's your role 
there, and what did you have to do with 
the upcoming Void Pirates? 

IF: D iversions Software was formed in 
1992, after I created the artwork for W in- 
Fish, a joint venture of 2 G uys Software 
(myself and A ndrew N ovotak). I am based 
in D enver and am the sole employee. M y 
role is "lone wolf," and I am responsible 
for every aspect of Void: code, art, anima- 
tion, sound, even ad copy and box design. 

GD: So what sort of projects has Diver- 
sions developed? 

IF: I currently have one retail product on 
the market- G rey W olf, a W W 1 1 U - 
Boat shooter— and a dozen shareware 
games and apps, including Prairie Dog 




part of the mix. 



New features in Caligari trueSpace2- such as three-dimensional booleans 
sionally rendered solid modeling- helped in the creation of this space station built into an 
asteroid, which players see from the main viewer on the bridge of their ship. 
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H unt 2-Judgment Day, second place win- 
ner in last year's Ziff-Davis Shareware 
Awards Two years of shareware develop- 
ment have included Prairie Dog H unt for 
W indows and its sequel, T rap Shooting, 
Fortress, TailGunner, StarGunner, and a 
few applications including StarTex, a star 
texture generator for rendering programs. 

GD: W hat's the connection with Sof- 
Source? 

IF: SofSource licensed rights to a few of 
my shareware games and, after I sent them 
a demo of G rey W olf in mid- 94, agreed to 
feed me while I developed that project. I 
was recently out of work as a database pro- 
grammer and jumped at the chance. I had 
always wondered why games 
cost so much to develop, so I 
set out to create G rey W olf for 
$5K and did. Void came next, 
with a little bigger budget. 

GD: How do you come to be 
making computer games? Are 
you an artist who's gotten 
into computers, or a techie 
type who's gotten into digital 
art, or someone who's always 
wanted to make computer 
games and just took on all the 
necassary roles, or what? 

I F: I think more the techie 
type. The last decade of my 
life has been spent as a mechanical design- 
er. I have been interested in graphics and 
3D work since 1985, when first exposed to 
it. I spent time as a kid attempting to write 
games for the Atari 800 in Basic, but got 
tired of it after getting a car. M y passion 
went from writing silly shooters for W in- 
dows to full-bore game development while 
creating G rey W olf. 

GD: W hat was that first exposure to 3D 
you just mentioned, and what about it 
interested you and inspired you to get 
involved? 

IF: M y first exposure to 3D was on an 
Applicon CAD CAM system at Stor- 
ageTek here in Colorado. From there I 
moved to AutoCAD. The first animation 



I did was a flyby of D urango airport with 
A utoC A D 9 i n 1989. J ust seei ng what was 
possible is what drew me into it, and I 
don't think it will ever end. 

GD: There's a lot of rendered 3D in Void 
Pirates, which I understand was done with 
Caligari trueSpace. W ith your CAD back- 
ground, how did you settle on that tool? 

I F: M y background in 3D includes 3D 
Studio, M acromodel, AutoCAD AM E, 
and anything else I could get my hands on. 
trueSpace was chosen due to price when 
G rey W olf began, and I quickly adapted to 
it. M oney was not available for 3D Studio 
and, even if it were, I would not have used 
it due to the fact that it is D S based. 




W hen Void Pirates started, I picked up a 
second system (P90), for rendering, and 
stuck with trueSpace. The only limitation 
was lack of 3D Boolean operations, but I 
still managed. W hen trueSpace2 showed 
up, I did go back and redesign some of the 
ships in the game using the new Boolean 
features. I also created some interesting 
stations built into tunnels on asteroids, 
which couldn't be done in trueSpace 1.0. 1 
just wish the motion blur option was 
faster. 

GD: W hat made you stick with trueSpace 
after Grey Wo If? 

IF: trueSpace is the easiest, most refined 
piece of software I 've ever seen. T here is so 
much packed into 1.2 M B of EXE : no 



DLLs, nothing. The interface is also the 
finest in the world, making designing so 
much easier. W in95 uses cascading menus, 
something I have hated since AutoCAD 
2.6. I can't believe M icrosoft would go 
back so far in user interface design. A noth- 
er reason for using trueSpace is the pletho- 
ra of game companies touting "3D Studio- 
Rendered Everything!!!" I want to be able 
to say "N ot a single thing was rendered in 
3D S, and not a single actor you will recog- 
nize!" M y actors are all people from a bar 
downtown and are working for beer. 

M oney is another reason. I don't have 
$4K plus another $5K for plug- ins for 3D 
Studio. I paid $469fortrueSpace...and I've 
seen some terrible 3D Studio stuff hit the 
shelves. 

I am shipping thetrue- 
Space2 demo along with 
some models with Void 
Pirates. 

GD: W hat other tools did 
you make use of to create 
the graphics for Void 
Pirates? 

IF: Everything was done 
on a D igital P90 with 
40M B of RAM , 2GB [of 
storage], and Stealth 64 
VRAM . Post production 
was done with Adobe Pre- 
miere and imsync RAZOR. 
All textures (400MB 
worth) and touch-up were done with 
Corel Photo- Paint 5+. Live footage was 
shot with a Sony H i-8 against my living 
room wall. Footage was captured with an 
Intel ISVR Pro card. All artwork in the 
game uses the Indeo 3.2 fixed palette. 
There is a bit of graininess because of 
this, but palette problems are hexed. 
T here is a little choppiness to some of 
the images, but I am willing to sacrifice 
image quality in favor of easy, flash-free 
palettes. 

GD: Let's talk about the look of the game. 
The sci-fi setting in Void Pirates is realistic 
and nicely detailed. W hat were some 
influences, and what did you try to do to 
differentiate your game visuals from sci-fi 
imagery we've all seen before? 
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IF: I was always impressed by the style of 
the original Aliens movie. The interior of 
the N ostromo was very well done— people 
smoking, porno magazines, empty coffee 
cups, and the two bobbing ducks in the 
main area really gave a realistic look to life 
in space. 

The Orinoco (the player's ship) was 
designed after looking at the mess on my 
desks here at home: ashtrays, soda cans, 
general disarray everywhere, but I still 
know exactly where everything is. Since 
space is dark, the overall mood of the game 
is dark; a sad future similar to Blade Run- 
ner. T he shininess and lighting of the Star 
T rek series always seemed too happy. Void 
Pirates focuses on trading of narcotics, 
stolen property, and the like, and a darkly 
lit design sets the mood (hopefully). The 
darkness also helps by masking areas where 
there should be more detail but I couldn't 
afford to put it in. 

GD: Couldn't afford in what sense? 

IF: Total budget was around $20K— this 
includes my rent and bills. Seven months, 
$20K, and one person is very little to create 
a saleable multimedia product these days I 
would love to spend twelve months on 
Void Pirates and $100K, but it isn't avail- 
able, so I have to create what I can with 
what I have in as little time as possible. 
The design was limited by what I could 
render with 40M B RAM , without hitting 
the swap file. T ime is limited developing a 
game with one or two systems T otal hours 
for modeling and rendering would be 
about 800 so far. 

GD: So far?W hat remains to be done? 

IF: M ore animations, more cut scenes. 
The still artwork is 99% finished. I think 
of something new each day. 1 11 spend thir- 
ty minutes trying to get an idea into true- 
Spaced. If I can't, I give up and try some- 
thing else the next day. 

GD: Will the game feature a lot of 
animation? 

IF: The majority of the animations are 
actual gameplay. Void Pirates uses many 
concepts from other games. Ships are 



attacked during strafing runs similar to 
Rebel Assault, displayed with an AVI. 
After disabling a ship, the hull is breached 
with a drone, which you then pilot 
around the interior of the ship as in Iron 
H elix. The animations are not the main 
point of the game, and I have tried to 
integrate them as seamlessly as possible. 
T here are also cut scenes that play as the 
player progresses through the game. 

GD: You voiced some strong opinions 
about user interface design earlier. ne of 
the great logistical and creative challenges 
in game design is creating an interface that 
manages tos atisfy all the various gameplay 
requirements, coexist peacefully with all 
the technical limitations of the minimum 
target system, be readily usable by the 
player, and stillf it the game milieu and 
look good. 

How did you approach this task in 
Void Pirates? 

IF: The Void Pirates user interface has 
changed only a little during development. 
I had grown tired of the single- screen user 
interface (such as Daedalus Encounter, 
Journeyman, Iron H elix) and wanted the 
player to see more. G rey W olf has a 
M yst-type interface, where the player can 
walk through the ship. T he only problem 
is a lack of crew members. 1 1 was basically 
a ghost ship, and the player had to do 
everything. 

In Void Pirates, the user interface 
consists of a main bridge screen with seven 
hotspots. F i ve of them take you to closeups 
of the control clicked on, and the other 
two take you to the M ain Cannon or the 
Gun Turret. Originally, a walkthrough 
design was used, but the image quality suf- 
fered from compression, so still image 
interfaces it was. The player can get tired 
of walking around the ship in short time- 
as in 7th G uest— so stills make sense. 

T o lose the ghost ship image, there 
is a VidPhone the player can use to talk 
to crew members. T he crew members are 
live video shot against blue screen here 
in my home. All communications with 
nonplayer characters are handled via 
remote video drones or a text based ter- 
minal. All selling and trading is handled 
in this manner, and the player never 



leaves the ship while in port. 

System requirements are M PC 2 for a 
minimum, DX2/66 8M B RAM recom- 
mended, accelerated video highly recom- 
mended. I expect a lot of people calling 
tech support saying their Packard Bell 
486/25 won't play the game. I've run into 
about 90% of G rey W olf customers having 
their systems set up wrong for decent 
W indows performance. The only limiting 
factor in the game is video card speed, and 
CD-ROM transfer speed. 

I did run into a problem with CD- 
ROM playback speed. M y limit of 270kps 
AVIs has caused a bit of image degrada- 
tion, and there are certain parts of the 
game where frames cannot be skipped. 
There is a graphics diagnostic program, 
along with VidTest in case the user needs 
to determine whether their system is 
M PC 2 compliant. 

GD: So what's next after you burn in 
Void Pirates? 

IF: I and two other developers are coming 
out with a Visual Basic GameToolkit, 
which will include a lot of source from 
Void, plus a replacement for Surround- 
Video (scrollable, scaleable virtual reality 
AVI files) I have come up with using 
Visual Basic and trueSpace. H opefully the 
Toolkit will get finished this year. It is in 
the planning stage right now, and I have 
very little time to work on it. It will 
include source for various types of games: 
scrolling, platform, shooters, AVI walk- 
throughs... Plenty of code for blitted but- 
tons, instead of the standard W indows 
look. The other two authors are contribut- 
ing sound and music goodies, and busi- 
ness multimedia stuff, as it isn't aimed at 
game design only. 

If we can find some capital, Andrew 
(WinFishguy) and I are going to hook up 
again. H e is working diligently with the 
Intel 3DR toolkit, and we are thinking 
along the lines of a networkable Tank 
Simulation, due to the speed of 3D R. 
W ith trueSpace, we should be able to cre- 
ate a very nice interface for a T ank. 

And yesterday, SofSource and I 
agreed on a vastly improved G rey W olf 2, 
for next spring. At least I don't have to 
wear a tie for another eight months. ■ 
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